I have a .net component that will be called by unmanaged code. I want to create an installer for the .net component that will in one step..
-install it to the desired directory
-generate the tlb file
-run the regasm command
The deployers of this component dont have knowledge of the .net framework.
Any ideas?
Thanks.
The type library only needs to be deployed if you want your client to use the component themselves when they write their own code using your COM server. That's unlikely given your description of their skills. If required anyway, you are better off simply deploying the .tlb yourself instead of auto-generating it during install.
Your client won't have Regasm.exe on their machine, it is only available in the Windows SDK. Nevertheless, registering ComVisible components is a standard capability of MSI. You can create your own installer that registers the component with a Visual Studio Setup project. Set the Register property to "vsdrpCOM".
It's been a while but I think something like this would work:
Add an Install.Installer class to your component, override it's Install and Uninstall methods and use RegisterAssembly to register the Assembly.
Then create a Visual Studio setup project and add a custom action to run your Installer methods during the setup.
Actually, here's a thread discussing just this and there's a comprehensive answer in there: http://www.dotnet247.com/247reference/msgs/18/90440.aspx
Related
I'm working on a .net core web app (targeting net461).
The app needs to reference a COM dll.
I added the COM reference and the app still builds on my dev machine.
However, on the build server it fails to build with this error:
C:\Program Files (x86)\dotnet\sdk\2.0.0\Microsoft.Common.CurrentVersion.targets(2604,5): error MSB4062: The "Microsoft.Build.Tasks.ResolveComReference" task could not be loaded from the assembly Microsoft.Build.Tasks.Core
After searching a bit, it seems like it's a pretty uncommon error.
Anyone know what the error is and/or how to fix it?
UPDATE: Seems like the dotnet CLI does not support COM references. Visual Studio uses msbuild directly behind the scenes, but on the build server, I was using the dotnet CLI commands.
WORKAROUND:
Reference the COM dll and rebuild. Visual Studio will generate an interop
dll. It will be named something like Interop.MyComDLL.dll. It is found in the build output directory.
Copy the generated Interop dll to somewhere in the application (I just
used a /dlls folder at the root application level).
Remove the COM dll reference.
Add a direct reference (Dependencies > Add Reference... > Browse in Visual Studio) to the Interop dll
It should also fail on developer machine if you try to build it using the same command as on build server, e.g.
dotnet.exe build Solution.sln --configuration Release --no-incremental
VS building solution using msbuild, it's a different way.
My suggestion would be to do any COM interop using dynamics, if you want to make it easier to change in the future, create an interface that that has all the COM properties and methods you need to access.
Create a class, implementing the interface, that creates the COM Object dynamically as part of the constructor. Then implement each of the methods and properties to access the the dynamic object you created.
This should remove any build time dependency, give an interface the rest of your code can depend on, and give an easy way out of the COM at a later date if required.
You might also find Rick Strahl's article for COM in .Net Core useful?
https://weblog.west-wind.com/posts/2019/Jan/22/COM-Object-Access-and-dynamic-in-NET-Core-2x
Hope this helps :)
I have a legacy project that uses a OCX. I had to register said OCX on my system using regsvr32.
Now, I want for Jenkins to compile the project. Unfortunately, in the Jenkins Server there is no OCX and I don't want to register it.
Is there a way to distribute the OCX so the project can compile on Jenkins? I read about registration-free components, but there seems to target runtime requeriments, and my issues are at compile time.
Yes - the way to do it is as Reza Aghaei says.
Call tlbimp to generate an interop assembly (it doesn't have to be a primary interop assembly). Then instead of referencing the ocx in the project, you reference the interop dll.
Note that if you want to run the project or use the control in the winforms designer you'll still need to register the ocx. Build for Building from Jenkins, this will work fine we use this technique to build our legacy code.
I've created a COM object in C# that later get's used by a VBScript. In order for the VBScript to be able to instantiate the object it must be registered. Previously I was registering the object manually using RegAsm tool supplied with any .NET Framework.
However, I am now creating an installer so I can install this object on different machines and when I am using InstallShield 2012 Spring Express it is warning me that the dll is not self registering.
How can I make my DLL self register? I've found guides and examples of folks using the Process object in C# to call RegAsm, but my object is not an executable.
Custom actions and Self Registration is NOT a best practice.
If your version of InstallShield doesn't support COM Interop, run the command:
regasm foo.dll /regfile:foo.reg
Now import that reg file into InstallShield and tweak things file foo.dll to [INSTALLDIR]foo.dll.
If your version of InstallShield doesn't support importing reg files, edit in notepad and enter the values into InstallShield by hand.
This is the cleanest approach as you won't have any custom actions to fail and since MSI is handling the registration it knows how to uninstall and rollback the data.
If you are using InstallShield, you can ask InstallShield to register your typelibs. In Components -> YOUR DLL -> .NET Settings -> Set .NET COM Interop to Yes.
In case you are using a version of InstallShield that does not support this, write a custom action which calls RegAsm.exe to register your dll.
I have an application that utilises the BouncyCastle framework, how can I package this application so that I don't have to manually put BouncyCastle's .dll on others computers? I'm assuming that this can be done with an installer or something similar? Where do applications look for referenced third party libraries by default?
As an alternate approach, you can inject assemblies into your main assembly.
There are cemmercial tools that support this like DeepSea Obfuscator or you can use ilmerge.
The general way of working is that you develop using separate assemblies and when you ship the product you do an additional build step that merges assemblies into one big assembly. You can even internalize the injected assemblies so only your public interface is accessible.
This way you can deploy your product as a single assembly which is especially nice if you're building components.
To answer your second question; the .NET framework will look in a couple of locations. The GAC is dominant but if you make sure the referenced assembly is in the same folder as your main assembly .NET will find it. No need to register it in the GAC.
Since BouncyCastle is a managed library, if you create an installer project in Visual Studio and add your application's exe to it, the installer will automatically detect the dependency on BouncyCastle, and add it to the installer project. When users install your application, BouncyCastle's dlls will be automatically copied to the installation directory and everything will be good.
You need to create installer. Best one to start with is ClickOnce. It will give you ability to put all needed files into one and provide UI for installation.
Second question. The default place to look for assemblies is GAC.
I have a web application from a company that has gone out of business. We're looking to extend the web app a bit with some asp.net functionality. The web app was written as an ISAPI application in Delphi, and uses COM+ to talk to the SQL Server and handles things like session management and authentication.
So, in order to get the current user and other details, I have to use the undocument COM+ components. I was able to dig out the type library and auto generated IDL, but at this point i'm lost in creating a .NET proxy class for this.
Is there a way to autogenerate the .net COM+ proxy either from the .dll itself (extracting the typelib info) or from the IDL?
Note: These seem to be simple COM style objects hosted in COM+ servers, no subscriptions or transaction monitoring..
You could use tlbimp.exe to generate C# proxy classes from your COM library.
tlbimp.exe myTest.tlb /out:myTest.dll
If you don't have the tlb it works also with COM dlls. Once the COM wrapper assembly generated you can reference it in your project and use the types inside as you would any other .NET class.
Possible location of tlbimp.exe : C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\TlbImp.exe or use the Visual Studio Command Prompt.
Run Tlbimp.exe on the type library to generate the .NET interop assembly for it.
Have you tried going to the references in your project, right clicking, add reference, then browsing to the dll. I think visual studio will generate the Runtime Callable Wrapper for you.