I haven't worked much with COM, so please forgive my ignorance.
Background: I am working on a project in VS 2010. There is a C# COM DLL integrated into the C# solution, and a Setup/Deployment project as well - the Setup project is set to register the COM .tlb file upon installation.
The problem: A previous version of the C# application, along with it's COM DLL, was present on a PC when someone decided to install the newest version of the C# application, and therefore the newest COM DLL. When this happened, it broke the COM functionality for both versions of the C# application..or that is what I am assuming has happened.
Is this typical COM/DLL-Hell behavior? When both C# applications are uninstalled, and then only ONE is re-installed, everything is back to normal - both apparently can't be installed at the same time.
I have tried changed the GUID for the COM DLL project, changing the AssemblyVersion and AssemblyFileVersion for the COM DLL project - all with mixed results. When I change those items, the new install of the application works (great), but now the old C# application doesn't have working functionality.
Note: there are no errors or exceptions thrown when the COM functionality is failing - the COM calls just seem to do nothing. So it is "silently" failing.
I have been researching this and trying various modifications to no real success...maybe I'm thinking about this the wrong way. Is there anyone else with more experience on this that could give me some insight?
You could use a merge module to install the com object and its successive versions. This would allow you to have multiple versions on the same machine. From Microsoft:
A merge module is like a snapshot of a particular version of a component. A new merge module should be created for each successive version of a component in order to avoid version conflicts.
Check out this link: Installer vs. Merge Module Recommendations
Related
I'm kinda new to C# programming, and I'd like your help on something.
A quick review of what I have to do first.
I have to create : - A DLL that produces several .h5 files (HDF5 format) and one xml file
- A WPF viewer for the graphs that are written in these HDF5 files.
The problem is mainly that they are going to be used in a software called Panorama E², which basically manages DLLs, in a very restrictive way. For instance, it does not allow .NET framework 4 (Which makes me use the 3.5 version of the framework).
More info on Panorama : http://uk.codra.net/panorama/panorama-e2-information-system
I'm using HDF5DotNet.dll, that I compiled in x64 for .NET 3.5, and DynamicDataDisplay for my WPF application.
All my DLLs are going to be used by another computer, where Panorama is installed, and where Visual Studio isn't (only the 3.5 .NET framework and some required tools are).
What's the problem ?
Well, first, my WPF application isn't really one, Panorama doesn't seem to support WPF, only Windows Forms, and only as DLLs. Which means I created a WPF UserControl, that I embed in a Windows Form DLL.
I basically have 2 DLLs, one which is the WPF control, and one that uses this control in a winform. This is the last one that I have to integrate in Panorama. On my computer, the one I'm coding with, Panorama recognizes correctly the DLL and there's no problem.
But when I try to give these DLLs to my colleague, with his Panorama without Visual Studio installed, it doesn't work. After some tests, I noticed that it only works if the project (the DLLs) have been compiled on the same computer.
The same problem goes for the other DLL, the one that creates files. As I said, it uses HDF5DotNet.dll, but it seems it doesn't create it correctly. I guess it's the same problem, the DLL is not recognized.
What I tried.
I thought that maybe the DLLs weren't exported correctly. Maybe the referenced DLLs or assemblies aren't given, which are when you compile on the same computer. They're COM DLLs, because they're used in Panorama, and I can't manage to export them correctly.
I tried creating setup projects, so that they would be installed with their dependencies, but I couldn't find a way. Only the DLLs are installed. I tried looking at my DLLs with DependancyWalker, and there are some where dependancies are missing. Even if I try adding them manually, nothing changes.
I also know that regsvr32 doesn't work with .NET DLLs, because there is no entry point. That's why i thought about GAC, but I can't manage to register them (with strong name and everything), because I can't generate them directly.
So yeah, sorry for the long post, I tried to explain my train of thoughts and what I actually tried to do, but I can't find a way to give my projects to my colleague so that he can use them on his computer.
"Self Registration" ( be it RegSvr32, RegAsm or other ) is not a Windows Installer Best Practice. This injects out of process dependencies into the installation critical path that the installer is not aware of, that can fail and can't be rolled back or uninstalled.
The better approach is to use RegAsm /regfile to harvest the COM metadata for the ComVisible assembly and then author those registry values into your MSI's Registry table. This way Windows Installer merely has to copy the DLL and apply the registry values to register your component. It's far less likely to break and can be uninstalled and repaired cleanly.
How you do this exactly depends on the tool you are using to author your MSI. In WiX you'd use Heat to harvest this information. In InstallShield you'd set the .NET ComVisible attribute to True.
The end result is the same.
Hi try the following in command prompt instead of regsvr32 try the following :
"RegAsm.exe acxMaterialClassificationMerge.dll /codebase " where acxMaterialClassificationMerge.dll is your dll. You should do this on every pc thats going to use the dll. RegAsm is located in C:\Windows\Microsoft.NET\Framework\v2.0.50727
1: install first dotnet framework version 2 or newer on the computer
2: in command prompt :"RegAsm.exe acxMaterialClassificationMerge.dll /codebase " where acxMaterialClassificationMerge.dll is your dll. You should do this on every pc thats going to use the dll. RegAsm is located in C:\Windows\Microsoft.NET\Framework\v2.0.50727.
I was tasked with building a C# 4.0 application that leverages an old VB6 COM component to integrate with another old VB6 application. The component was built strictly for this integration, and is deployed by my application.
I built an installer for my C# application using Visual Studio Setup project, and added that COM component to the list of deployed files. Installer auto registers/unregisters the component beautifully.
However, the issue I have now is that after uninstalling the application on my development box I can't debug the application without registering the COM component again by hand since the uninstall unregistered it. I'm not implying the uninstall shouldn't unregister the COM component. I'm just trying to figure out a better way of making sure we can still build and test both the application and installer on our development boxes without this inconvenience.
P.S. I tried using a DllImport, but it never finds the entry point. From what I understand from research you can't really use a DllImport on a COM component. I hope I didn't miss something.
You're pretty much doing the right thing and the installer has to unregister the COM component unless you want to encounter some really problematic effects on customers machines.
Unfortunately there isn't much you can do apart from maybe writing a simple CMD file to re-register the COM component after you tested the installer.
The application I'm talking about consists of vb6 (80%) and c#, .Net Framework 4.0 (20%).
All new components are created with c#. With Microsoft Interop Forms Toolkit 2.1 we create the COM UserControls that we later embed in vb6. For Forms we use normal classes to create and open in vb6 (COM Visible project).
To create the setup we use wise.
Locally everything works fine - The problems only occur when we install the application on a non-developer machine with the wise created setup.
We added a class to open a c# Form to an existing interop toolkit project. It works fine on the developer machine and also when we make a new installation on a pc(non-dev-machine). The new class is just used to open the form.
But when we update our application to a newer version, that class is not working anymore. We have to uninstall the old version and install the new version to make it work again.
Anyone had a similar problems before?
I'm grateful for any advice
This seems like it is an issue with Windows Installer and the sequencing during the upgrade. Does your application allow side by side installs (e.g. Version 1 and Version 2 can be installed at the same time) or does your installer upgrade earlier versions to the latest version? You might try logging the installation and reviewing the log file to see exactly what is happening during the install / upgrade process.
You can log an msi installation by invoking Msiexec from a command line.
This may provide greater insight and help focus your efforts to debugging the problem.
Edit
From what you've described it seems that on fresh installation the install works as expected. When you upgrade earlier versions it would seem that the COM Interop components are not registered properly. This could be an indication that the sequence of events is a little off with regards to when the components are copied to the machine and registered vs. when the existing product is removed. While not exactly identical, see this SO Question and answer for more details. Also, have a look at the RemoveExistingProducts action in Windows Installer for more information.
I would log an installation that you know works without issue (e.g. on a "clean" machine) and then log an installation that you know will fail (e.g. an upgrade) and then compare the two log files using a tool to see if the output is identical. If not, that gives you a clue as to where to look. If they are identical it might be time to engage with the vendor and see if they can assist with determining what's causing the issue.
Before I change to ExcelDNA,
My addin is COM AddIn, developed in C#, VS 2008 for Excel 2003+
my installer is created via Setup project in VS 2008
during install, install.xls is called in Custom Action, which calls an xla to register my UDF
Now, I switch to ExcelDNA,
My addin is changed to
public class Connect : ExcelRibbon, IExcelAddIn
I still use Setup project in VS, keep the same upgradeCode,
during install, install.xls is called in custom action, which calls an xll to register my UDF
This works fine for a new install i.e. there is no older version
However, if there is an older version of myAddin (COM Addin)
if I install new version of my Addin (excelDna version) on top of it,
I expect the new version will overwrite the older verison.
However, an error comes up saying "A problem occurred while an addin was intialized (InitializedFailed)..."
Maybe many people here have similar experience before.
How did you solve the issue? thanks a lot !!
This is related to signed projects.
I used to have two projects(dll) signed and referenced by third dll. Later I remove signing.
and reference unsigned dlls in the third dll.
When I upgrade from previous version, for some reason the two dll are not updated.
So the third one looks for unsigned version of dlls while only find signed version in installation folder. So I got the error of initializedfailed.
I signed both dll again and reference them in my third dll, then upgrade works fine.
more info http://blogs.msdn.com/b/tomholl/archive/2007/04/19/avoiding-configuration-pitfalls-with-incompatible-copies-of-enterprise-library.aspx
However one issue is, why those two dlls are updated during new install and are NOT during upgrade install?
Is this a bug in windows installer or something I miss? thanks
My program is written in C# NET 2.0,it's using external functions from a dll written in C++ using Microsoft Visual Studio 2008 SP1.
If I remove the dll from the directory the program is placed,the program crashes at the moment it should use the dll.That's normal.
But the users that are using my program get the same error at the same place without moving the dll.They all have C++ Redistributable 2008 from >here<
Does it happen because I made the program in .NET 2.0 instead of NET 3.5 or it happens ,because the redistributable should be an older version?
Edit:Note for me,the program runs fine.
>>new thread<<
Its most likely the wrong runtime. Make sure you are distributing the correct one. These will always work on your dev box because the runtimes are in the path. For testing software, I use a windows xp virtual machine. I set up the virtual machine as a completely fresh install, install the components I know that I need (.NET framework, etc.), then run my installer. You will run into a surprising number of setup issues doing this.
The C++ Redistributable that you linked to looks like it is from the original release of Visual Studio 2008. If that changes with SP1, I could see that causing the crash. Maybe there is an updated version of the redistributable that your users need to install?
There's preciously little information in your question about the actual crash which could mean any of many things. In my experience with mixing .NET and native C++, many issues can occur in the side-by-side (SxS), especially if the DLL and the .NET application were built with different versions of the compiler.
You probably need to reproduce this problem on a local machine to debug it.
Dependency Walker can be excellent for tracking down these sorts of problems. You can load a DLL into it and it will tell you if any of its dependencies are unavailable. Sometimes missing DLLs are not necessarily a problem (if you do not go down that code path), but it is so much better than guessing.
No difference in this context of using .NET 2.0 or 3.5.
Look in method where you link and export functions from C++ (if it unmanaged)
If external functions had written on managed C++, look into signing and version of dll's