|
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 | |
Share:
|
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
| | |
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
| | |
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
| | This discussion thread is closed Replies have been disabled for this discussion. Similar topics
18 posts
views
Thread by Clark Nu |
last post: by
|
5 posts
views
Thread by Arun Bhalla |
last post: by
|
10 posts
views
Thread by Eric E |
last post: by
| | | | | | | | | | |