A
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
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