I am referencing a VB6 dll in my dot net project.
to do this I need to register the dll using regsvr32 tool.
when i build my project the Interop dll is getting created in obj folder and not bin folder.
Do I need to add the VB6 dll to wix project and register it. If yes how do I achieve it.
I tried adding it to wix project but as its not created in bin folder i am getting error.
Could anyone please help me on this.
Thanks
You install the vb6 Dll the same as any other file, with the addition that the Heat tool is used to harvest the registration entries from it. You don't need regsvr32.
If you want your interop dll in a specific location at build time, I suggest you explicitly use the tlbimp.exe tool to create the interop dll in the required build location so the WiX build can find it.
Related
I have a DLL with tools i use in several projects. The DLL is frequently updated with new functions. How can i automate the replacement of the DLL in a way so that i dont have to manually copy and paste?
The way i do it now is that i build my project with visual studio, manually copy the DLL file from bin/debug folder and paste them into the root folder of the different projects that use it.
I know gacutil is used to register DLLs to the GAC and that i can make a batch file that does this.
If i install it to the GAC and the projects reference them there, will they be updated? What typicall options are there?
You should look into packaging the library as a NuGet package.
If that doesn't work for you, there's post-build events in Visual Studio that you can use so that the copy & paste is done automatically for you.
I know people normally add a dll file into the reference of Visual Studio very easily as follow:
1) Right Click on Reference
2) Choose Add Reference
3) Browse and choose dll file
However, with this approach, VS seems to store the absolute path, pointing to my dll file, rather than copy dll file into VS's project memory.
What if I remove the dll file from the hard driver? or what if I want to deploy the project on another computer?
Sorry, I am quite new to .Net
As described in your question, this is the way you reference a class library or any other DLL-like reference.
Once compiled, your project copies its dependencies into its bin folder where you can find the referenced DLLs.
If you can't find the referenced DLL, set its Copy Local property to true.
Another way around is to set your Reference Paths. This will force, on compile-time, your project to update itself with DLLs from the specified reference paths.
The best practice was to create a Shared folder where all referenced libraries were in, so that you could write your reference paths once and for all per project.
Technologies being so great and vast on improvements, there's now NuGet Package Manager.
What is NuGet?
A collection of tools to automate the process of downloading, installing, upgrading, configuring, and removing packages from a VS Project.
How to use NuGet?
You may install it from within Visual Studio if it is not already installed, through the Extension Manager.
Otherwise, please visit the NuGet CodePlex Home Page.
Here's how Finding and Installing a NuGet Package Using the Package Manager Console has never been easier! =)
So when you open up an existing project, NuGet manages to get all the dependencies for you without any more effort from you. This should solve your concerns.
I have a C# project (let's call it Driver) that uses an unmanaged DLL to interact with some hardware. I have another project that references Driver. When I build the project, the unmanaged DLL gets copied to the output directory as I want. However, when I publish the project as a ClickOnce application, the DLL does not get included in the application's files.
In the Application Files in project properties under Publish, I can see Driver's managed DLL, but the unmanaged DLL is not listed.
I'm certain there's an easy fix for this, but searches mostly lead to questions about including unmanaged DLLs in projects.
Thanks in advance,
Bjørn
After researching this some more, it seems that the solution is to add the DLL as an existing item in all the projects that use it. It seems, however, very clunky if you have multiple projects depending on it.
I have a Class library project. I am installing this dll produced by the project into the GAC by the command "gacutil /i [Path of the dll]". This dll is used by a windows application. When windows application runs, it successfully accesses the functions and properties of the dll.
Now I have made some changes to the dll. I have uninstalled the original dll from the GAC and will install the newer dll with the required changes. Now when the windows application uses this dll, the new changes from the dll are not getting reflected in the application. The new changes should reflect into the application as I installed the new dll into the GAC.
The Name, version and Public key token is the same for both dlls. I think it won't matter as the i have uninstalled the previous dll and installed the new dll into the GAC.
Am I doing something wrong?? Please suggest a solution.
Thanks and Regards,
Mayur Mahajan
I would suggest for debugging purposes that you version your dll, then print the version to your application to be sure its being updated. Include the System.Reflection namespace and the code would run look like the following:
Assembly assembly = Assembly.LoadFrom("unknown.dll");
label.Text = assembly.GetName().Version.ToString();
So I have this C# project that requires the use of some functions from a vc++ library. This vc++ library is then dependent on other vc++ libraries.
So in order to get this working, I created a c++/cli dll project that wrapped the main vc++ library. In the project linker settings, I just added the target vc++ library in the input field, and this resolved linker errors. I then added a reference to the cli project to the c# project references.
Everything compiled fine, but when I ran the C# project, there was a File.IO.Exception saying that the cli dll couldn't be loaded. After some tinkering around, I found that this error was happening because the wrapped vc++ dll dependencies could not be loaded. So I copied the vc++ dll into the same folder as the c# exe. I also had to copy all of the other vc++ dlls that the initial dll depended on.
Having to keep track of all of the VC++ dlls is burdensome, so I'm wondering if it is possible to statically link all of the VC++ dlls into the C++/CLI dll, so I do not have to copy them into the same folder as the C# exe. I tried adding all of the vc++ dependencies to the linker input field but that didn't do anything.
Thanks,
Alex