[RESOLVED] MSI deployment and Vista

[superdave]

Hi there,

I think this is the best area to ask this question.

I have changed my MSI to install to c:\ProgramData. I am not certain if this directory exists in XP, but that is not the issue, at the moment.

When I run my program, any writes to the database in this directory get virtualized and thus my DB mods get put into the virtual directory under c:\user\......

What do I change to get my DB writes to not get virtualized? From what I read, this is the appropriate place.

Thanks. Dave

[dilettante]

Where to begin?

Well you have the right filesystem location. That's a start. Beyond this there are two other factors involved:

• Your program needs to have full read/write capabilities if it is to create and update files in the subfolder you place under this folder.
• To prevent virtualization you need to tell Vista that you are Vista-aware.

These steps are not needed if your program will only read files from your CommonAppData (a.k.a. "ProgramData") subfolder. Otherwise your MSI package will need to set the necessary permissions on this subfolder when it creates it.

Note:

You should not put files into CommonAppData, only into created subfolders within CommonAppData.

To inform Vista that you know what you're doing (Vista aware) you need an application manifest with a <trustInfo> element in it. More specifically one with a completed <requestedExecutionLevel> element within it. A separate manifest file will work, though in general an embedded manifest is better.

Note:

Doing this will mean your program will get no AppCompat coddling automatically. If you break any rules from here on, your program will fail when it runs.

Ok. So how do we do all this?

I've attached a small sample application with instructions in a ReadMe.txt that may help you. This file concludes:

What Did We Accomplish?

We have changed VSI 1.1's per-user MSI into a per-machine (all users) package.

We have made up for the lack of an easy-to-use capability in VB6 to have an Everyone-writable common filesystem location the way we once used App.Path.

We have tested and confirmed its operation.

How Was This Done?

Part of the magic is in the program. Based on whether running in IDE mode or not we used App.Path or an API call to build a working path for our settings and data files and folders.

The Project's AppEx class was used to encapsulate some of this functionality. One could just as easily hard code the necessary API calls inline to save a little space, but I find AppEx a handy "drop in" extension class for XP/Vista development. You might trim it down or add other functionality you often find a use for.

Secondarily we leveraged VSI 1.1 to create a basic MSI package.

Thirdly we post-process the MSI using a small WSH script. This script changes the VSI 1.1 per-user install into a per-machine install. Most of the script goes a step further and causes Windows Installer to make our application data folder Full Access for Everyone.

Conclusion

VB6 applications can be first-class citizens in the XP/Vista world. While we don't have manifest creation and embedding built into the VB6 tools we have alternatives.

VSI 1.1 isn't comprehensive as an application packager, but with the help of Orca.exe and a little bit of WSH scripting we can extend it in many useful ways. It's free and creates packages that are more friendly for corporate deployment than "legacy script-based" installer technologies.

And now you have a place to put those MDBs and such once again.

I hope this helps. Sorry there is so much to absorb at once. There isn't really much to it but it does get a little finicky. Think of it as competitive advantage. Not many VB6 developers have mastered it. Very few know how to get it all wrapped into a working MSI package.

The good news is that lots of .Net developers have the same issues to deal with and don't have it figured out yet either.

[superdave]

Thank You!!!!!!!!!!!!!!!!!!!!!!

An example is super! I appreciate this. I will review it and post any questions I might have, but I suspect this should do the trick. I have been googling for something like this and the closest I came to something good was a MS blog from a guy answering this question, but saying, use WIX. I'm not certain I want to go down that path...yet. I figured, I was pretty close.

Thanks again!

Dave

[superdave]

I should have mentioned that I am using VB.NET with VS2008. I should have put that in most post, but forgot about that.

[dilettante]

Ooooooops!

Sorry I goofed there myself. I see that .Netizens indeed do need this help. Perhaps you can fish out what you need from the material I posted anyway?

Look at the hints about setting up the MSI, and then modifying it via the script included.


P.S. WIX is something I keep shying away from myself. I looks like a lot of thrashing and typing to accomplish anything useful.

[superdave]

I have reviewed your program and have learned a few things.

1) My program did not have the manifest file in the installed directory. By not having this file in the program files directory in whichthe program is installed, my program works fine, but it uses virtualization.

2) Adding the manifest to the MSI and running the install, causes the program to fail as you said it would. Changing the manifest settings for requestedExecutionLevel only makes it fail differently, but it still fails.

So, now what I would like is to change my installer to allow writing to the programData directory. To do this, I assume I have to run something like your script. I guess, I was thinking that there was a way to configure the installer to do this... Second, how do you modify the installer to automatically run this script when the MSI runs?

Thanks, Dave

[dilettante]

You're getting there!

I was using VSI 1.1 to build my MSIs because that's all we poor VB6 beggars have without spending some $$$. If you have a decent Edition of VS.Net (maybe Standard, Pro for sure) the installer that is built in may let you create and set permissions on the required folder.

Newer VS Installers like those in VS.Net probably also offer the option of a "post build" action which could be such a script as mine. This script is run after building the MSI, it is not needed during deployment.

However a newer VS Installer (build utility) probably will allow you to set up everything you need without any script. There are commercial 3rd party MSI makers that can do this for sure.


You might also consider MAKEMSI which is freeware and should be a lot easier than WIX.

[superdave]

Well, I went back and forth a couple times between the Windows Installer built into VS2008 and WIX.

I ended up using WIX and it was pretty darn easy to do. I like the WIX help that comes with the package. I have read that VS will include WIX in a future release, so I figured I am ahead.

Thanks for the help.
Dave

[dilettante]

Glad to hear it. I think we'll hear more about WIX as they improve the GUI front end to build the XML and as people take a serious look at it.