current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
stack overflow careers
Sign up ×
Stack Overflow is a community of 4.7 million programmers, just like you, helping each other. Join them, it only takes a minute:
up vote 1 down vote favorite

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.

share|improve this question
    
You sound very lost and unable to gather sufficiently usable evidence for the problem. Clearly you'll need help from the vendor. – Hans Passant Jun 21 '13 at 15:49

3 Answers 3

up vote 0 down vote accepted

"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.

share|improve this answer
up vote 0 down vote

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

share|improve this answer
    
Hi, thanks for the answer. I saw a lot of references to regasm.exe. The thing is, regasm.exe isn't installed on this specific computer. Can this program be installed without installing Visual Studio, and can it be uninstalled afterwards ? – user2508093 Jun 21 '13 at 12:15
    
I tried this on my computer, and it tells me my DLL is not a valid .NET assembly. Which is kinda weird, I guess... – user2508093 Jun 21 '13 at 12:27
    
What version of regasm did you use? The one in 2.0? – Renier Jun 21 '13 at 12:42
    
Have a look at this :www45.brinkster.com/b3ck/code/dllcreation.html – Renier Jun 21 '13 at 12:52
    
@user2508093 try the above. – Renier Jun 21 '13 at 13:03
up vote 0 down vote

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.