basic deployment & version numbering

[hawbsys]

Can anyone help with two basic questions about deployment?

First question. We deployed a WinForms application recently and it was
successful. We opted for the simple "publish" method via a CD. This
created an installer which placed the application in the folder C:
\Documents and Settings\[user]\Local Settings\apps\2.0\[....]\[....]\
[....]. Now, although this worked, it does mean every user on every PC
needs to run the setup to use the app. There's no "install for all
users of this PC" option. And also, there are some paths and other
settings (once they would have gone into an INI file) which have to be
set in the .config XML file. So that's a lot of editing of that file
(which isn't even that easy to locate). What are we doing wrong? Apart
from the fact that everything worked fine it's a tedious lot of
setting up. Other than building a separate setup project inside our
solution is there a better way? Does everyone deploying non-trivial
WinForms apps create a separate setup project?

Secondly, there appear to be three separate versioning schemes built
into a .net project. There's the Assembly Version and the File
Version, both available under "Assembly Information" in Project
properties and both can be incremented manually. Then there's the
publish/build versioning which increments automatically when you
"publish" and which is built into the folder names when you publish.
Only the Assembly Version can be reached in code, so far as I can
tell, by reading My.Application.Info.Version.ToString. What are the
differences between these three version numbers and how to people
typically use them? Is there a way to refer to the "publish" version
(the one that advances automatically) in code?

How do others use the version numbering in vs2005 in their winforms
projects?

 

[hawbsys]

ahem ... sorry about the duplicates. things went a bit screwy there.

hawb

 

[VJ]

Answer to your second question...
1. Assembly Version is normally incremented so you can install 2 versions of
the same dll, this is if you choose to install in the GAC. This is mainly
for application feature upgrades
2. File Version is primarily for Source Code control and for your own
internal tracking of what changed between builds. Mostly for small patches
and bug fixes.

Answer to your first question
No matter how trivial the project is, if it goes to a user base, Please use
MSI packaging to deploy applications, gives you a option to Install for all
users. You can do this with Setup Deployment of MS project in VS 2005 or
using InstallSheild like tools. Also you have easier options to upgrade.
If you are in closed office network to deploy then you can try something
like SMS from a domain server to roll changes... I am not very familiar with
SMS, just know its a Tool to deploy changes to a networked users with Domain
Server...

VJ

Can anyone help with two basic questions about deployment?

First question. We deployed a WinForms application recently and it was
successful. We opted for the simple "publish" method via a CD. This
created an installer which placed the application in the folder C:
\Documents and Settings\[user]\Local Settings\apps\2.0\[....]\[....]\
[....]. Now, although this worked, it does mean every user on every PC
needs to run the setup to use the app. There's no "install for all
users of this PC" option. And also, there are some paths and other
settings (once they would have gone into an INI file) which have to be
set in the .config XML file. So that's a lot of editing of that file
(which isn't even that easy to locate). What are we doing wrong? Apart
from the fact that everything worked fine it's a tedious lot of
setting up. Other than building a separate setup project inside our
solution is there a better way? Does everyone deploying non-trivial
WinForms apps create a separate setup project?

Secondly, there appear to be three separate versioning schemes built
into a .net project. There's the Assembly Version and the File
Version, both available under "Assembly Information" in Project
properties and both can be incremented manually. Then there's the
publish/build versioning which increments automatically when you
"publish" and which is built into the folder names when you publish.
Only the Assembly Version can be reached in code, so far as I can
tell, by reading My.Application.Info.Version.ToString. What are the
differences between these three version numbers and how to people
typically use them? Is there a way to refer to the "publish" version
(the one that advances automatically) in code?

How do others use the version numbering in vs2005 in their winforms
projects?

 

[hawbsys]

Answer to your second question...
1. Assembly Version is normally incremented so you can install 2 versions of
the same dll, this is if you choose to install in the GAC. This is mainly
for application feature upgrades
2. File Version is primarily for Source Code control and for your own
internal tracking of what changed between builds. Mostly for small patches
and bug fixes.

Answer to your first question
No matter how trivial the project is, if it goes to a user base, Please use
MSI packaging to deploy applications, gives you a option to Install for all
users. You can do this withSetupDeployment of MS project in VS 2005 or
using InstallSheild like tools. Also you have easier options to upgrade.
If you are in closed office network to deploy then you can try something
like SMS from a domain server to roll changes... I am not very familiar with
SMS, just know its a Tool to deploy changes to a networked users with Domain
Server...

Thanks for these pointers.

Hawb