Posts

Visual Studio 2010, Ensure Application EXE is always updated no matter what.

/in /by

I wrote before about how to make sure that an .msi produced by a Visual Studio 2010 setup project correctly overwrites the application executable when installing an application update. Now the recommended techniques worked well for C# applications but I found that did not work reliably for VB apps for some random & annoying reason. No matter how many times I changed assembly and file versions etc. etc., the blasted thing would never update the installed .exe file!

 

So the only reliable way I found to make sure that the .exe was always updated was to use Orca to edit the .msi file and set the .exe’s version number to:

 

65535.65535.65535.65535

 

To set this version number right click on the .msi and choose ‘edit with Orca’, Click on ‘File’ in the ‘Tables’ section on the left of the screen, you should then see your .exe listed along with its version number. You can change the version number here and then save.

 

This ain’t pretty but its is the only way that I could get the installer to work reliably…

 

Windows Installer – The Specified path is too long with subst.

/in /by

I was testing an installation script (produced by a Visual Studio 2010 set-up project) on a open box virtual machine and was intermittently getting a lovely error message telling me that the ‘specified path is too long’, even though the path that the error message displayed as being incredibly short.

 

Anyway, I was installing to a subst’ed drive in an attempt to match the clients IT set-up and it seems that the windows installer just doesn’t work well with subst at all. So, to get around the problem I removed the subst’ed drive and instead added another virtual drive to the virtual box machine and everything worked ok.

 

So I know there are many many reasons for the ‘specified path is too long’ installer error message (most of which have nothing to do with long paths at all!) but one thing is for sure – installing to a subst’ed drive is one cause!

 

Get a Visual Studio 2010 .NET Setup Project to Update a Previous Installation

/in /by

Here is a good post about getting an Visual Studion Setup project to generate a .msi that will update a previous installation rather than demanding that the existing install be uninstalled before it can be reinstalled:

 

http://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects

 

I followed the steps in the ‘How to update your product’ section.

 

The only catch is that the setup project will only update files that have had their version number changed even if the files them selves _have_ changed. To ensure that all files are included in the installation package, I had to make sure that all of the projects in my solution changed their version numbers on each build, to do this I edited each project’s AssemblyInfo.cs file and replaced:

 

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

with:


[assembly: AssemblyVersion("1.0.*")]
//[assembly: AssemblyFileVersion("1.0.0.0")]

This causes a new version to be generated on each build and forces the set-up project to include them in the installation package!

 

Allow Normal (non-service) App to write to Windows Event Log

/in /by

Here is a very handy article that explains how you can alter your app’s setup project in Visual studio to install an Event Log Component so that your non-service app, when installed, can write to the windows event log without getting security errors:

 

http://msdn.microsoft.com/en-us/library/f5dcf6h3(v=vs.80).aspx

 

Visual Studio 2010 Setup Project HRESULT = ‘8001010E

/4 Comments/in /by
 

A setup project I was working on in Microsoft Visual Studio suddenly stopped building with the following error;

An error occurred while validating. HRESULT = '8001010E'

When I tried to refresh the dependencies I got a nasty error message. If found this post and played with the suggested settings a bit without any joy. Then I shut-down visual studio and restarted and the build error went away! So if this happens to you all I can suggest is to take a look at this post or restart Visual Studio, or both!

 

Visual Studio, #pragma once not working?

/in /by

Software development can sometimes be a comical affair, I have just been caught out badly by a strange gotcha – it appeared that #pragma once stopped working on a Visual Studio C++ project on which I have been working.  I was getting plenty of error messages about redefined classes! 

 

Well it turns out that I had left a copy of one of my header files lying around in one of the project folders.  As pragma once uses a header file’s full path to figure out if it has already opened it, a situation arose whereby both files were included and compile errors flooded in (despite the pragma onces)!

 

Well removing the (accidential) copy of the header file fixed the problem – boy do I feel stupid, I hope this post may help someone with a similar problem in the future!