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 3 2456
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 thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Clark Nu |
last post by:
It seems that when I define a fuction,I can set a default value to some of
the peremeters.When I call the fuction without some of them,the fuction will
use the default value automaticlly then...
|
by: Arun Bhalla |
last post by:
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.*"...
|
by: Eric E |
last post by:
Hi all,
I am using an Access client linked to a PG 7.4 server via ODBC.
I have a stored proc on the server that inserts rows into a
table.particular table, accomplished via an INSERT
within the...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
| |