There will be additional point releases before the next major version.  StrataFrame 2.0 will be released after .NET 3.5 and will be a major overhaul (but don't worry, we will make sure things are backwards compatible and that you have a way to migrate forward ).  But just like the 1.6.1 release, there will be some feature rich releases between now and the next major release.

Know this is an old thread, but in case anybody is thinking about going down the ClickOnce path we've been there, done that, and have found that it is far from perfect for every type of client app and deployment scenario. We're abandoning it for either the suggestions here or for now, just using plain old Windows Installer or the Application Updater Block.



The app we are trying to launch in production is only about 5 or 6 PCs, all have local SQL Express but each PC is used by several different users with separate login, which isn't a good scenario with Clickonce since each user has to get their own update which is sort of a pain.



For the most part we had it working during acceptance testing but when we needed to create separate test/live installs on the same PCs we just could not make it fly with ClickOnce - found some articles on web that said it could be done but we just couldn't get past cryptic errors and odd behavior, etc.



That said, we have used ClickOnce for some internal .Net apps that do not require the same test/live environments on the same PC and it works fine, for the most part, for this scenario. We just do all of our testing in the dev environment for the most part.



So yeah, I would definitely say if you're not careful ClickOnce can quickly become Click5000

LOL...thanks for your input Randy...I have felt your pain before, brother!

Randy,



I have a few scars on my forehead from high speed impacts with my desk that occurred during my early days with Click-Once(More...). I actually got it work though.



My scenario is that most of my users are remote, using ES to connect to the database...except when proxies stop that, in which case they are using a VPN. It's been fun.



Click-Once(More...) actually has been a whole lot better than dealing with installers, which have to be copied out to the users, then we end up installing it for them. It used to take 2 weeks to get a new version installed when using installers (not may users, but they are a busy lot). Now it just happens. I would gladly stop using Click-Once(More...) if SF commercialized their installer though!



I have up to four versions of the same app installed on a machine via Click-Once(More...): build, beta, training and production. I was even deploying obfuscated apps via Click-Once(More...) for a while! So, if any of you decide to go down this route and need help, holler and I'll share what I know!

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.