This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Basic MSI: COM assemblies, how to get away from using batch files
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
Dec 05, 2013
05:51 AM
Basic MSI: COM assemblies, how to get away from using batch files
I will confess that I know very little about COM and assemblies outside of how to register them using regasm.
I have been trying to get away from using batch files for registering seven .NET 4.0 assemblies using regasm. However, I have not been successful and I know it is because of my lack of understanding of how this should work.
I can see that COM has been extracted to the MSI database. However, when I start my application, I get errors. When I manually register the assemblies using regasm the application will work. I take this to mean that I did something wrong in setting up my assemblies in the component to extract the COM.
I have been reading through Josh Stechnij's white paper on "What Installation Authors Need to Know about COM Extraction", however, I do not think I am any closer to better understanding how to set this up correctly in my project.
Currently our batch file is setup like this:
%WINDIR%\Microsoft.NET\Framework\v4.0.30319\regasm AmazingCharts.MainBusinessObjects.dll /unregister
%WINDIR%\Microsoft.NET\Framework\v4.0.30319\regasm AmazingCharts.MainBusinessObjects.dll /tlb: AmazingCharts.MainBusinessObjects.tlb
What I want is to create the identical output in the MSI table. I have the VS2010 .tlb file that I can add to the project and extract data, but I do not know how to associate it with the AmazingCharts.MainBusinessObjects.dll, or that I need to. These are things that I do not know about COM. 🙂 I had tried just adding the .tlb files, but I still did not get a successful start to my application. The application checks that these files are registered and reports errors if not.
In the end, I would much rather have all these .NET assemblies part of the MSI table for the sake of resiliency and a cleaner system on uninstall or rollbacks.
Please also note that it is important that I register my .NET assemblies in a certain order. If I do not, then the registration will fail. I am not certain if this plays a factor in how COM Extraction works for InstallShield or not - I was trying to determine this from Josh's white paper, but could not see how it resolves dependencies and sets the order of registration.
Thank you for any insight anyone can provide. It is kindly appreciated.
I have been trying to get away from using batch files for registering seven .NET 4.0 assemblies using regasm. However, I have not been successful and I know it is because of my lack of understanding of how this should work.
I can see that COM has been extracted to the MSI database. However, when I start my application, I get errors. When I manually register the assemblies using regasm the application will work. I take this to mean that I did something wrong in setting up my assemblies in the component to extract the COM.
I have been reading through Josh Stechnij's white paper on "What Installation Authors Need to Know about COM Extraction", however, I do not think I am any closer to better understanding how to set this up correctly in my project.
Currently our batch file is setup like this:
%WINDIR%\Microsoft.NET\Framework\v4.0.30319\regasm AmazingCharts.MainBusinessObjects.dll /unregister
%WINDIR%\Microsoft.NET\Framework\v4.0.30319\regasm AmazingCharts.MainBusinessObjects.dll /tlb: AmazingCharts.MainBusinessObjects.tlb
What I want is to create the identical output in the MSI table. I have the VS2010 .tlb file that I can add to the project and extract data, but I do not know how to associate it with the AmazingCharts.MainBusinessObjects.dll, or that I need to. These are things that I do not know about COM. 🙂 I had tried just adding the .tlb files, but I still did not get a successful start to my application. The application checks that these files are registered and reports errors if not.
In the end, I would much rather have all these .NET assemblies part of the MSI table for the sake of resiliency and a cleaner system on uninstall or rollbacks.
Please also note that it is important that I register my .NET assemblies in a certain order. If I do not, then the registration will fail. I am not certain if this plays a factor in how COM Extraction works for InstallShield or not - I was trying to determine this from Josh's white paper, but could not see how it resolves dependencies and sets the order of registration.
Thank you for any insight anyone can provide. It is kindly appreciated.
(1) Reply
Dec 05, 2013
08:56 AM
Let me start with a point of clarification. While the overall idea of extracting COM information into the MSI is the same for both native COM and managed assembly, when you're talking the .NET regasm case, you need to use the .NET COM Interop setting instead of the COM Extract at Build setting. If you're not, start there; otherwise continue along here.
Historically there's been two major differences between our .NET COM Interop extraction and running the regasm command at run time. The first is all good: you don't have a run-time dependency on regasm. But the second was use of regasm's /regfile option; this inherently excludes any changes that might be made by user-defined register functions, so the results can differ in significant ways if someone is using or abusing user-defined register functions. I don't recall if our more recent approaches have removed this caveat (I know we talked about using our newest COM extraction methods to monitor regasm without the /regfile parameter, rather than reading the reg file that /regfile created, but I don't know if we actually implemented it yet).
As far as a dependency order of registration, that's exactly what extraction tries to avoid at run time, however it is susceptible to it at build time depending on build machine state. The newest approaches are capable of referencing dependnency's COM registration if it's already registered on the build machine, but at the same time these approaches are not always able to extract all registration information when the COM server itself is already registered. (I'm sure Josh could go into all sorts of detail on why this happens, but the short version is not all self-registration/unregistration routines are fully symmetric. The end result in the worst case is that some work is never repeated so we cannot capture it.)
To save yourself some work, I might suggest building a small project with just the file you want to COM extract, then seeing what InstallShield's build (or perhaps static COM extraction) finds. If it's missing just a few pieces, and you can find them, you can certainly add those back to your main project; perhaps that's all it would need in order to make your application work correctly.
Historically there's been two major differences between our .NET COM Interop extraction and running the regasm command at run time. The first is all good: you don't have a run-time dependency on regasm. But the second was use of regasm's /regfile option; this inherently excludes any changes that might be made by user-defined register functions, so the results can differ in significant ways if someone is using or abusing user-defined register functions. I don't recall if our more recent approaches have removed this caveat (I know we talked about using our newest COM extraction methods to monitor regasm without the /regfile parameter, rather than reading the reg file that /regfile created, but I don't know if we actually implemented it yet).
As far as a dependency order of registration, that's exactly what extraction tries to avoid at run time, however it is susceptible to it at build time depending on build machine state. The newest approaches are capable of referencing dependnency's COM registration if it's already registered on the build machine, but at the same time these approaches are not always able to extract all registration information when the COM server itself is already registered. (I'm sure Josh could go into all sorts of detail on why this happens, but the short version is not all self-registration/unregistration routines are fully symmetric. The end result in the worst case is that some work is never repeated so we cannot capture it.)
To save yourself some work, I might suggest building a small project with just the file you want to COM extract, then seeing what InstallShield's build (or perhaps static COM extraction) finds. If it's missing just a few pieces, and you can find them, you can certainly add those back to your main project; perhaps that's all it would need in order to make your application work correctly.
