In the Assembly Information, you can set the assembly version and the
file version. What is the difference between the two? The
documentation is not exactly helpful in this area.

I had the assembly version set to a unique number, and just left the
file version as 0.0.0.0. My program crashed on another computer, and
the windows error report stated: "AppVer: 0.0.0.0", so I am thinking
maybe the file version is more important (unless this was an older
version of my program that had BOTH assembly and file version set to
0.0.0.0).

When you right-click properties of a file, it shows the File version
at the top, and both assembly and file versions inthe list box at the
bottom, with assembly listed first.

It is totally unclear to me what either is for, which is more
important. For now, I'll just set them to both be the same.

Zytan

Without trying to sound daft, the assembly version controls the
version of the assembly, and the file version controls the version of
the file. If may be useful to keep them in sync, but note that
"fusion" uses the assembly version as part of the identity when asking
"is this the right dll". The file version is not really used so much
by .Net, but may be used by OS tools. Changing the assembly version of
a strongly named assembly generally requires you to tell the callers
to forward to the new version (via policy), else recompile.

Right or wrong, I have tweaked my build process to timestamp the build
into the file version, but it leaves the assembly version for manual
planned change. That way I can always track the history of a dll,
without quite as much pain for releasing a hotfix as changing the
assembly version.

Marc

Hi Marc,

Would you mind share with us how u did it?


Thanks,
Ignacio

"Marc Gravell" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Without trying to sound daft, the assembly version controls the
> version of the assembly, and the file version controls the version of
> the file. If may be useful to keep them in sync, but note that
> "fusion" uses the assembly version as part of the identity when asking
> "is this the right dll". The file version is not really used so much
> by .Net, but may be used by OS tools. Changing the assembly version of
> a strongly named assembly generally requires you to tell the callers
> to forward to the new version (via policy), else recompile.
>
> Right or wrong, I have tweaked my build process to timestamp the build
> into the file version, but it leaves the assembly version for manual
> planned change. That way I can always track the history of a dll,
> without quite as much pain for releasing a hotfix as changing the
> assembly version.
>
> Marc
>

Nothing very sophisticated I'm afraid. I considered some funky MSBuild
add-ins, but chickened out. Basically I have a build script (actually
a C# exe) that traverses a source tree looking for things to build
(updating references / dependencies, setting config for the
environment [WCF endpoints, etc], figuring out the build order etc); I
simply added a few lines into that which use a regex to find and
update the necessary attribute in the source code. Similar to the
standard VS auto-versioning, but with an offset that won't run out of
numbers for a few extra decades.

Sorry it wasn't something more exciting ;-p

Marc

Ok, so basically the assembly is one whole compilation, and that has a
number. But, the file version refers to the final .exe made, so it is
also the entire assembly. I still fail to see the difference.

Maybe someone can explain what the difference between file and
assembly is in terms of a final exe file?

Thanks,
Zytan

>Maybe someone can explain what the difference between file and
>assembly is in terms of a final exe file?

You can create so called multi-module assemblies, where one assembly
spans over more than one executable file. It's not that common, but in
such a scenario you'd have a single assembly version while each
executable could have its own file version.


Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

> You can create so called multi-module assemblies, where one assembly
> spans over more than one executable file. It's not that common, but in
> such a scenario you'd have a single assembly version while each
> executable could have its own file version.

Ok thanks, Mattias

Zytan