By Larry Caylor - 7/18/2007
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
|
By Trent L. Taylor - 7/18/2007
Hey Larry,You can go about this a number of ways. But in essence, we have the clients verify their version each time the application is launched. A query is made to the server to get the latest version, if the servers version does not match the clients, then it begins an automated download from the server. Once downloaded, the client automatically launches the installation, which is automated, and once the install is complete, it re-launches the client. Doing it this way will ensure that the security permissions are kept in tact. If you need to run the install as a different user, you can do that as well by launching the install process with more advanced permissions (i.e. Administrator). In any case, this allows you to create a more reliable and sophisticated installation than ClickOnce will allow while still making it easy to distribute to the clients. Does that answer your question or are you looking for more of the details?
|
By Larry Caylor - 7/18/2007
Trent,Thanks for the summary. The one area I'd like a little more information on is the automated download process. I'm assuming that your install processis using the standard windows installer with the installation package put together using InstallAware. -Larry
|
By Trent L. Taylor - 7/18/2007
Gotcha. Well, there are a couple of ways to tackle this. In either case, as mentioned above, you need to have a version table on the server that the client can test against. We use teh assembly version of the main EXE to determine the version.On your server, you will also need to have the install stored in a database...or stored in a network folder location where all of the workstations can access it. In most cases, the database is the better and more secure route. Example Structures VersionTable
ver_pk - Integer (Primary Key)
ver_CurrentVersion - VarChar (Holds the current version that the client will test against)
ver_Posted - DateTime (Time stamp that indicates when the version was changed....this would be for display purposes only) DownloadsTable dl_pk - Integer (Primary Key)
dl_CurrentVersion - VarChar (Allows you to query by the version for the download)
dl_Install - VarBinary(MAX) (The installation in Byte() format) Application Startup When the application on the client side starts, check the version to see if there is an update. Dim lcMyVersion As String = Reflection.Assembly.GetExecutingAssembly().Version.ToString()
Dim loVersions As New VersionsTableBO() If Not lcMyVersion.Equals(loVersion.GetCurrentVersion()) Then
'-- Get the installation from the server
Dim loDownloads As New DownloadsTable()
'-- Retrieve the install
loDownloads.FillWithCurrentInstall(loVersion.GetCurrentVersion())
'-- Save the install to a temp folder
Dim lcTempLocation As String = System.IO.Path.GetTemporaryFile()
'-- Change the extension
lcTempLocation = System.IO.Path.ChangeExtension(lcTempLocation,".exe")
'-- Save the bytes to disk
System.IO.File.WriteAllBytes(lcTempLocation,loDownloads.dl_Install,True)
'-- Launch the install
System.Diagnostics.Process.Start(lcTempLocation)
'-- Terminate the client assembly
End
End If Note: I just typed this code out here so there could be some minor things to work through, but it should give you the general idea. If I went in the wrong direction with your question, please let me know and I will try to give you some more details.
|
By Ben Hayat - 7/19/2007
Trent, thanks for the valuable info.
Got a question/suggestion for you. Have you considered of offering a new product/components (general enough) that would allow us to use with our application that whether on the same network or remote users can get updates using ES? When I was using Delphi, one of the third party companies offered a complete set of components that we could add to the app and the upgrade was right built into the application without much efforts.
You have done it, tested it and works and it would make a great additions to your products list. Honestly, I think even people who don't use SF, would buy and use this module and I bet you can sell ES for their remote users. Think about it and I would be your first customer 
Thanks!
|
By Larry Caylor - 7/19/2007
Trent,Thanks for filling in the details. I think I can take it from here, however I like Ben's suggestion. I'd be the second one to buy it. -Larry
|
By Greg McGuffey - 7/19/2007
After struggling with Click-Once, I'd be the third 
|
By Trent L. Taylor - 7/19/2007
LOL ....well I think Ben's idea is a good one and maybe it is something we can put on the table for the next major release. We are all about producing product that our developers are interested and....and that can make life much easier Thanks for all of your input!
|
By Paul Chase - 7/19/2007
I would like to get a hold of the guy that named it click-once!!. I clicked waaaaay more than once!
|
By Ben Hayat - 7/19/2007
we can put on the table for the next major release.
So Trent, are you ready to tell us what your time frame is for the next major release? Will there be other releases like 1.7, 1.7.1, 1.8, ... before getting to 2.0? Or 2.0 is going to be after the 1.6.x?
Any insight [if you can] would be appreciated!
|
By Trent L. Taylor - 7/19/2007
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.
|
By Randy Jean - 10/2/2008
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
|
By Trent L. Taylor - 10/3/2008
LOL...thanks for your input Randy...I have felt your pain before, brother!
|
By Greg McGuffey - 10/3/2008
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!
|
By Randy Jean - 10/7/2008
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
|
By Greg McGuffey - 10/7/2008
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.
|
By Greg McGuffey - 10/7/2008
Oh, I forgot to provide an example of how I've got the different versions setup:
TypeNameProduct
------------------------------------------------------------
BuildMyCompany.MyApp.BuildMyApp - Build
BetaMyCompany.MyApp.BetaMyApp - Beta
ProductionMyCompany.MyApp.ProductionMyApp - Production
|
By Greg McGuffey - 10/7/2008
jeesh, it wacked my formatting...
Type Name Name
-------------------------------------------------------------------
Build MyCompany.MyApp.Build MyApp - Build
Beta MyCompany.MyApp.Beta MyApp - Beta
Production MyCompany.MyApp.Production MyApp.Production
|
By Randy Jean - 10/7/2008
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
|
By Greg McGuffey - 10/7/2008
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.
|
By Randy Jean - 10/7/2008
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.
|
By Greg McGuffey - 10/7/2008
I glad it was helpful. Let me know if you have any other questions, I'll try to help out!
|
By Greg McGuffey - 10/8/2008
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!
|
By Trent L. Taylor - 10/8/2008
Yup, every day It is a good app!
|
By Randy Jean - 10/20/2008
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: <Assembly: AssemblyFileVersion("1.0.0.1")> 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.
|
By Randy Jean - 10/20/2008
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....
|
By Trent L. Taylor - 10/21/2008
Correct, that is part of our build process which assigns the file version to our assemblies.
|
|