In the last SF calss Trent mentioned that you had developed a custom solution for distributing client software for your medical apps rather than usning MS one-click deployment. I don't remember all of the details so it would be helpful if you could provide a brief outline of the approach you took and any issues I should look out for.

-Larry

Hi Greg,

I would be very interested in knowing exactly how you got different versions to run on the same PC with ClickOnce. We deploy from a web server. In house we have a "staging/dev" deployment which works fine but at the client site we need test/live running on same PC. We have all the database stuff working with DDT, etc., just not the different app versions.



We tried all the suggestions, changing the "name" (which name, there are only a 1/2 dozen places where "name" could apply), using a different key file, etc. Struggled with trying to use MageUI, etc. Really got discouraged fast after many attempts. FYI, we were trying this under vs2005 but have since moved to vs2008 and have not gone back to try to see if there is any improvement.



We actually thought about using virtual PC but problem with this is our app uses virtual serial ports (up to 16) through a USB hub so didn't wan to try to get that to work with a VPC.



Thanks,

Randy

Randy,



Here is the basic process I use.



1. EVERY build must have a unique version on the publish page. So, if I have a build version out for testing (1.0.0.0), then move it to beta for user acceptance with no changes to code it becomes 1.0.0.1, then move it with no changes to production it becomes 1.0.0.2. This is true even though each of these is theoretically a separate installation. If you don't do this, bad things can happen (failed installations, corrupting your click-once installations). The assembly and/or file version can be whatever they need to be. My splash form shows the publish version, not the assembly or file version so the user doesn't get confused (they will see the publish version on the publish.htm page).

2. I publish the application. I always set the Publish Folder Location AND the Installation URL. The Publish Folder Location (1 in image below) is local (some place in my local file system). The Installation URL (2 in image below) MUST be the URL the users will use to get to the .application file used to install the application. Note that the publish.htm can be someplace else, but it must point to the .application file at the Installation URL.







3. Once published, I use MageUI to update the version specific .application file (see below) so I can run multiple version of the same app. In MageUI, you need to update, the Name on the Name page and the Product on the Description page. See attachments for images.



The name + product determines unique installation





The product name appears in Click-Once dialogs. I also use it in my splash/about forms.





4. Always select the .manifest file, even if it is already correct. This ensures that the hashes are correct.







5. Save in MageUI, which updates all the hashes.

6. Replace the .application file referenced by publish.htm with the version specific one changed in #3 above.



In VS 2005, when an application is published, the folder structure looks something like the following:







where:

1 is the version specific folder containing the .deploy files and the .manifest files.

2 is the generic .application file called by publish.htm to install the application via Click-Once.

3 is version specific .application file that can be used to roll back installation at the server.



In step #3 you modify the version specific .application file, then in this step you delete the generic .application file, copy the version specific file and rename it to the generic version. (Hope that make sense.)



In VS 2008, it's a bit different, but same concepts apply. With VS 2008, an Application folder is created and within it there is a version folder. Within in this folder is an .application file for that version. In the root install folder, there is a copy of that file also. So, in step #3, you modify the .application file in the version folder, then copy over the generic .application file in the root folder.



Since I'm still targeting .NET 2.0, I haven't noticed any improvements yet, as the improvements are when you use .NET 3.5 and are not dependent on which version of VS you use (though as noted, VS 2008 publishes using a different folder structure).



I hope this gets you going in the right direction (or satisfies your curiosity : ). Let me know if you have more questions.

Oh, I forgot to provide an example of how I've got the different versions setup:

jeesh, it wacked my formatting...

Excellent! That is much better than any of the blog or forum posts I found on the internet where they tried to explain what to do. I will definitely give this a try and let you know how it goes.



Thanks,

Randy

Good luck! Oh, and I still didn't get the little table showing an example of how I setup the different versions right. The last column should be labeled Product.

Well, I was just told NOT to do this as the client and their IT department have now said not to use ClickOnce (for their own reasons I assume) - but, we definitely plan to use it for other projects and for other clients so I still appreciate the great info and hopefully it may help someone else out here as well.

I glad it was helpful. Let me know if you have any other questions, I'll try to help out!

I've gotten some PM regarding the program I used to make the screen shots I used in the Click-Once post. I figured I'd just post it here for anyone curious.



I used Snag-It (http://www.techsmith.com/screen-capture.asp). If my memory is correct, I learned about it right here in this forum, when someone asked the SF guys (or maybe it was Ivan) what program they used. I'm also pretty sure that SF uses it for screen captures in their help files. In any case, it is a rocking program!

Yup, every day   It is a good app!

Figured I'd just keep this thread going

So, for the most part, using a deployment project to create windows installer (MSI) vs. Clickonce has paid off and everything is finally working how we want with separate test/live environments, etc.

However, one snag I ran into which I had a somewhat difficult time figuring out, was with performing upgrades.  There are all sorts of how-to articles on the web which are outdated (ie. apply to VS 2005) - apparently, with 2008 deployment projects there is yet another version that must be taken into account and that is the "file" version.  In other words, incrementing the installer version and productcode is not enough. ANY files which are being deployed and have their own "file" version (ie. .NET assemblies) must have that version incremented as well if you want those files replaced.  This is true even if you have RemovePreviousVersions set to True.  That said, I finally got our upgrade to work by changing the file version (which is located just below the assembly version in the VS 2008 IDE Assembly information dialog) and can also be set in the assemblyinfo.vb file like so:

My concern is now with Strataframe assemblies... Does Microfour increment the file version on these?  Reason I ask is that I see the following when I view the source project in VS:

In the assemblyinfo.vb I don't see any file version, however, in the dll I see:

So, I'm not sure where the 1.6.5.3 comes from and also do not know if this doesn't change and there are SF dll updates, will these get updated on the client deployment correctly?

See file versioning rules:

http://msdn.microsoft.com/en-us/library/aa368599(VS.85).aspx

Again, this is new with 2008.  2005 as long as you bumped the installer version and had RemovePreviousVersion all files would be replaced.

By the way, thanks to Charles Hankey for telling me to use IE so I could insert images the correct way.  Didn't even think to try that last week when I was having all sorts of trouble doing this.

Doh! Here I go again answering my own questions.  Actually looked at the assemblyversion.vb file (there are actually more than one of these in the DBengine project?)

And saw this:

[codesnippet]<Assembly: AssemblyFileVersionAttribute(MicroFour.StrataFrame.BuildInformation.BuildVersion)>[/codesnippet]

So I'm guessing that means this is part of your build process and I should not worry about it....

Correct, that is part of our build process which assigns the file version to our assemblies.