Installer "Catch 22"(?) and Versioning

Arun Bhalla

I'm borrowing some code from Pavel's Command Prompt Explorer Bar installer
to use in my own explorer bar's installer.

Recently I've been thinking that using an assembly version like "1.0.*"
(hence, for example, "1.0.1304.25935") would be useful, at least for
development and debugging purposes. (Someone please point out the cons to
this idea!)

Well, anyway, Pavel's installer basically exists to register the assembly,
and unregister the assembly at uninstallation. So it all comes down to
getting the relevant assembly so it can be fed to
RegistrationServices.RegisterAssembly().

Currently the code for getting the relevant assembly looks like this:

Assembly VisITBarAssembly{ get { return
AppDomain.CurrentDomain.Load("VisIT, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=4d504ee06f99380a"); }}

This works because the version is hardcoded to "1.0.0.0" in Installer.cs as
well as AssemblyInfo.cs. I'd like to remove this string from Installer.cs so
I can only worry about AssemblyInfo.cs whenever I want to bump up a version
number. (Bonus points if I could remove the need to change both
AssemblyInfo.cs and the version number in the Setup project! Additional
bonus points if I can access the Setup project's "Manufacturer" etc. fields
from the application, but I guess the best (or only?) solution would be to
use the Registry.)

So what are some good ways to go about this? I think using the Registry
might be one way to go about it, having to store the assembly's full name
somehow (programmatically) in a registry entry. Personally I think it would
be nicer to avoid it, but hey! If I assume a constant GUID, then I could
look it up in the registry (it's already stored there, but then again, this
might implicitly get stored from the RegisterAssembly call).

It would be even nicer, I think, to have a dynamic GUID, that allows the
GUID to change with the Product GUID (set in the Setup project), but I don't
know if that's feasible.

And furthermore, what can I do with the savedState object that is an
argument to so many Installer event handlers?

Any tips, comments, or smooth suggestions?

Thanks,
Arun

Jul 19 '05 #1

David Barnard

I _think_ you are making this far harder than it should be. If the assembly
you are registering is the same assembly that the installer class is in,
then all you need to do is grab the executing assembly.
Assembly.GetExecutingAssembly();

If this is not the case, then you should be able to load the correct
assembly with a partial name, and grab the version from there (only you
won't because you will have the correct assembly already!).
Assembly.LoadWithPartialName(name); // you will need to ensure the correct
assembly is in the correct place for this to work.

Or, if you only know the filename, you can just load the file.

I'm afraid there is no way to synchronise versions across projects, and yes,
you will have to use the registry to get the additional information you
need.

David

"Arun Bhalla" <bh****@arun.groogroo.com> wrote in message
news:eH**************@TK2MSFTNGP10.phx.gbl...

I'm borrowing some code from Pavel's Command Prompt Explorer Bar installer
to use in my own explorer bar's installer.

Recently I've been thinking that using an assembly version like "1.0.*"
(hence, for example, "1.0.1304.25935") would be useful, at least for
development and debugging purposes. (Someone please point out the cons to
this idea!)

Well, anyway, Pavel's installer basically exists to register the assembly,
and unregister the assembly at uninstallation. So it all comes down to
getting the relevant assembly so it can be fed to
RegistrationServices.RegisterAssembly().

Currently the code for getting the relevant assembly looks like this:

Assembly VisITBarAssembly{ get { return
AppDomain.CurrentDomain.Load("VisIT, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=4d504ee06f99380a"); }}

This works because the version is hardcoded to "1.0.0.0" in Installer.cs as well as AssemblyInfo.cs. I'd like to remove this string from Installer.cs so I can only worry about AssemblyInfo.cs whenever I want to bump up a version number. (Bonus points if I could remove the need to change both
AssemblyInfo.cs and the version number in the Setup project! Additional
bonus points if I can access the Setup project's "Manufacturer" etc. fields from the application, but I guess the best (or only?) solution would be to
use the Registry.)

So what are some good ways to go about this? I think using the Registry
might be one way to go about it, having to store the assembly's full name
somehow (programmatically) in a registry entry. Personally I think it would be nicer to avoid it, but hey! If I assume a constant GUID, then I could
look it up in the registry (it's already stored there, but then again, this might implicitly get stored from the RegisterAssembly call).

It would be even nicer, I think, to have a dynamic GUID, that allows the
GUID to change with the Product GUID (set in the Setup project), but I don't know if that's feasible.

And furthermore, what can I do with the savedState object that is an
argument to so many Installer event handlers?

Any tips, comments, or smooth suggestions?

Thanks,
Arun

Jul 19 '05 #2

Arun Bhalla

Hmm, I'll look into it. Currently (and presumably, always) the installer is
not in the same assembly.
The installer is "Installer.exe," and the assembly is just a DLL.
Assembly.LoadWithPartialName() might
do the trick. I imagined that I might have to iterate through a bunch of
assemblies with a certain name and try
to find the assembly with some appropriate version number (perhaps the
maximum version number).

Thanks,
Arun
"David Barnard" <ms*************@didactylos.net> wrote in message
news:u8**************@TK2MSFTNGP11.phx.gbl...

I _think_ you are making this far harder than it should be. If the assembly you are registering is the same assembly that the installer class is in,
then all you need to do is grab the executing assembly.
Assembly.GetExecutingAssembly();

If this is not the case, then you should be able to load the correct
assembly with a partial name, and grab the version from there (only you
won't because you will have the correct assembly already!).
Assembly.LoadWithPartialName(name); // you will need to ensure the correct
assembly is in the correct place for this to work.

Or, if you only know the filename, you can just load the file.

I'm afraid there is no way to synchronise versions across projects, and yes, you will have to use the registry to get the additional information you
need.

David

"Arun Bhalla" <bh****@arun.groogroo.com> wrote in message
news:eH**************@TK2MSFTNGP10.phx.gbl...

I'm borrowing some code from Pavel's Command Prompt Explorer Bar installer to use in my own explorer bar's installer.

Recently I've been thinking that using an assembly version like "1.0.*"
(hence, for example, "1.0.1304.25935") would be useful, at least for
development and debugging purposes. (Someone please point out the cons to this idea!)

Well, anyway, Pavel's installer basically exists to register the assembly, and unregister the assembly at uninstallation. So it all comes down to
getting the relevant assembly so it can be fed to
RegistrationServices.RegisterAssembly().

Currently the code for getting the relevant assembly looks like this:

Assembly VisITBarAssembly{ get { return
AppDomain.CurrentDomain.Load("VisIT, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=4d504ee06f99380a"); }}

This works because the version is hardcoded to "1.0.0.0" in Installer.cs as

well as AssemblyInfo.cs. I'd like to remove this string from Installer.cs so

I can only worry about AssemblyInfo.cs whenever I want to bump up a

version

number. (Bonus points if I could remove the need to change both
AssemblyInfo.cs and the version number in the Setup project! Additional
bonus points if I can access the Setup project's "Manufacturer" etc.

fields

from the application, but I guess the best (or only?) solution would be

to use the Registry.)

So what are some good ways to go about this? I think using the Registry
might be one way to go about it, having to store the assembly's full name somehow (programmatically) in a registry entry. Personally I think it

would

be nicer to avoid it, but hey! If I assume a constant GUID, then I could
look it up in the registry (it's already stored there, but then again,

this

might implicitly get stored from the RegisterAssembly call).

It would be even nicer, I think, to have a dynamic GUID, that allows the
GUID to change with the Product GUID (set in the Setup project), but I

don't

know if that's feasible.

And furthermore, what can I do with the savedState object that is an
argument to so many Installer event handlers?

Any tips, comments, or smooth suggestions?

Thanks,
Arun

Jul 19 '05 #3

Suzanne Cook [MS]

Don't use LoadWithPartialName(). See
http://blogs.gotdotnet.com/suzcook/P...3-56c29a59b22d
for why not. That may help you in the development environment, but will
come back to haunt you in the shipping code.

Instead, for development purposes, I recommend that you just not change your
assembly version between shipping builds. See
http://blogs.gotdotnet.com/suzcook/P...3-56c29a59b22d
for details.

Suzanne Cook
My .NET CLR Loader blog: http://blogs.gotdotnet.com/suzcook/
--
Please do not respond directly to this alias. This alias is for newsgroup
purposes only. This posting is provided "AS IS" with no warranties, and
confers no rights.

"Arun Bhalla" <bh****@arun.groogroo.com> wrote in message
news:uE**************@TK2MSFTNGP12.phx.gbl...

Hmm, I'll look into it. Currently (and presumably, always) the installer is not in the same assembly.
The installer is "Installer.exe," and the assembly is just a DLL.
Assembly.LoadWithPartialName() might
do the trick. I imagined that I might have to iterate through a bunch of
assemblies with a certain name and try
to find the assembly with some appropriate version number (perhaps the
maximum version number).

Thanks,
Arun
"David Barnard" <ms*************@didactylos.net> wrote in message
news:u8**************@TK2MSFTNGP11.phx.gbl...

I _think_ you are making this far harder than it should be. If the assembly

you are registering is the same assembly that the installer class is in,
then all you need to do is grab the executing assembly.
Assembly.GetExecutingAssembly();

If this is not the case, then you should be able to load the correct
assembly with a partial name, and grab the version from there (only you
won't because you will have the correct assembly already!).
Assembly.LoadWithPartialName(name); // you will need to ensure the correct

assembly is in the correct place for this to work.

Or, if you only know the filename, you can just load the file.

I'm afraid there is no way to synchronise versions across projects, and

yes,

you will have to use the registry to get the additional information you
need.

David

"Arun Bhalla" <bh****@arun.groogroo.com> wrote in message
news:eH**************@TK2MSFTNGP10.phx.gbl...

I'm borrowing some code from Pavel's Command Prompt Explorer Bar installer to use in my own explorer bar's installer.

Recently I've been thinking that using an assembly version like "1.0.*" (hence, for example, "1.0.1304.25935") would be useful, at least for
development and debugging purposes. (Someone please point out the cons to this idea!)

Well, anyway, Pavel's installer basically exists to register the assembly, and unregister the assembly at uninstallation. So it all comes down to
getting the relevant assembly so it can be fed to
RegistrationServices.RegisterAssembly().

Currently the code for getting the relevant assembly looks like this:

Assembly VisITBarAssembly{ get { return
AppDomain.CurrentDomain.Load("VisIT, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=4d504ee06f99380a"); }}

This works because the version is hardcoded to "1.0.0.0" in Installer.cs as

well as AssemblyInfo.cs. I'd like to remove this string from Installer.cs

so

I can only worry about AssemblyInfo.cs whenever I want to bump up a

version

number. (Bonus points if I could remove the need to change both
AssemblyInfo.cs and the version number in the Setup project!

Additional bonus points if I can access the Setup project's "Manufacturer" etc.

fields

from the application, but I guess the best (or only?) solution would be to use the Registry.)

So what are some good ways to go about this? I think using the

Registry might be one way to go about it, having to store the assembly's full

name somehow (programmatically) in a registry entry. Personally I think it

would

be nicer to avoid it, but hey! If I assume a constant GUID, then I could look it up in the registry (it's already stored there, but then again,

this

might implicitly get stored from the RegisterAssembly call).

It would be even nicer, I think, to have a dynamic GUID, that allows the GUID to change with the Product GUID (set in the Setup project), but I

don't

know if that's feasible.

And furthermore, what can I do with the savedState object that is an
argument to so many Installer event handlers?

Any tips, comments, or smooth suggestions?

Thanks,
Arun

Jul 19 '05 #4