I was creating a set up project for a COM class. So users can install the dll and get additional features as an option. However i labelled the COM Class so i renamed the dll. However when i changed the dll from class.dll to comclass.dll, and ran regAsm again, when i added the comclass.dll to the project the .tlb was class.tlb listed in the Detected Dependencies folder, keeping the old name.
So i decided to create a new project with new GUIDs to just fix it and named it comclass.dll. Everything tested and compiled but once i got to the set up portion of and added the comclass.dll, nothing was showing up in detected dependencies only .net framework. Before the old .dll use to get the .tlb to show up. Now i can't get the .tlb to show up.
If i add the .tlb directly to the project it gives an error at set up time regarding the setup not being able to register the .tlb file.
Related
I've been doing facial recognition program in .NET. I made it work but it uses DLL that you have to add as reference. It works on my PC, but when I try to clone my GitHub repo and try to run the program, the compiler says that references are missing:
When I manually add the reference that is in DLL folder, it works- THE REFERENCE IS DOWNLOADED FROM REPO BUT NOT RECOGNIZED. So the DLL downloads but its not recognized as the reference until it's added manually. How could I fix this?
I tried adding the reference again, but it didn't work. I also tried to make new project and to change the directory of DLL. I also tried to change the .gitignore because I thought that could be the problem but It's not.
I have a Visual Studio (2015) project, written in C#, that is dependent upon an external dll (say a.dll), written in C++. This in turn is dependent upon other libraries (say b.dll, c.dll), also written in C++. These in turn are dependent upon some boost libraries. I have no control over any of the libraries, but they must be used to complete the project.
Adding library a.dll to the visual studio project is fine. I can add it as a reference and that works. However, it does not run, because the other libraries are not present.
When I try to add b.dll and c.dll to my project, then I get an error:
A reference to 'a.dll' could not be added. Please make sure the file is accessible, and that it is a valid assembly or COM component.
Using this answer (https://stackoverflow.com/a/12639732/5503148) I tried running TlbImp, and got this error:
TlbImp : error TI1002 : The input file 'b.dll' is not a valid type library.
If I copy the libraries to the output folder manually, or get them copied automatically by adding them to the project (not as references), then it all runs.
However, in the end result the project needs to have a dependency on the libraries. That way they can be loaded into another third party product.
Is there a way to do this manually - i.e. tell Visual Studio that the library a.dll is dependent upon other libraries?
I have a C# project which builds a library DLL, myLib.dll. This DLL has a dependency on a 3rd party DLL, dep.dll (which I provide but do not build).
I want others to be able to use my library by adding my project to their solutions and referencing it. Adding my project as a reference automatically copies myLib.dll to the Target directory of their app, but of course dep.dll is not copied with it.
Bear in mind that I have no control over where my project is in their code tree, and the DLL can't know where it was copied from.
The only solution I can see is to force the user to add a build event which copies dep.dll to their target directory. We can't assume users can create environment variables.
This is very undesirable for several reasons (it's not really one dependency - I simplified things, I don't want them to have to be concerned about the dependencies in my project, and it's very fragile - adding an extra dependent DLL to my project would require everyone to update their build scripts).
I can't load the dep.dll directly as I don't know where it is - my build scripts can copy it to the same target directory as myLib.dll but the actual version of myLib.dll they run will have been copied somewhere else.
I also can't make dep.dll a reference directly (probably because it's not a .NET assembly). I just get "Error loading code-completion information for dep from dep.DLL. Format of the executable (.exe) or library (.dll) is invalid".
So is there any way to have the dependent DLL just seamlessly copied with myLib.dll when a client builds their application? [I'm using Sharp Develop if it matters.]
Can you add dep.dll to your projects root folder as a file like a .cs file. Set the Build Action to None and Copy to Output Directory to Copy if newer.
At work, we have a VB6 project (ActiveX DLL) that we need to be able to add as a reference to another VS2008 C# project.
A developer there tells me that in the past, they have been able to do so but now we made a change to the VB6 DLL and had to recompile it.
As such, we need to update the reference in the VS2008 project but when we try to add the reference to the VB6 DLL back (after removing the old reference) to the VS2008 project, we get a yellow "!" icon on the newly added reference and then when we build, VS2008 says the reference cannot be found.
I tried the "Browse" and "COM" tabs where you can add reference, no luck.
Do we need some kind of TLB to be able to add it or something ?
Thanks.
You need to do the following from a command prompt:
#CD to wherever the dll is located
regsrv32 /u foo.dll
regsrv32 foo.dll
This will unregister the old com object and register the new one.
He's right, you could do that from command prompt.
Remember though, your Active-X control DLL could be 16-bit, so use
regsrv /u foo.dll
regsrv foo.dll
from command prompt. But 32-bit works fine for regsrv32!
I used OLE/COM object viewer (included in Windows SDK 6.0A) then I saw a bunch of COM entries in "All objects" ie: MyDLLName.className and some were pointing to a DLL file which did not exist anymore. Deleted all the relevant COM entries in the Windows registry that pointed to the deleted DLL and left all the ones which pointed to the existing DLL and then I could import it successfully in my VC# project.
One solution (the.sln)
One C++ project (mycppproject.vcxproj in 2010or mycppproject.vcproj in 2008) which compiles a native DLL exporting some function(s). In debug this builds c:\output\Debug\mycppproject_d.dll and in release this builds c:\output\Release\mycppproject.dll.
One C# console application (mycsharpconsole.csproj) containing PInvoke calls into the DLL.
All compiles fine.
When I build, I would like to be able to add a reference from the csharp project to the cpp DLL project so that it can copy the appropriate file from the appropriate directory into the \bin\Debug directory the csharp project is built into.
This should be possible, since the IDE knows everything there is to know about where the DLL gets built, and where the C# application gets built.
In Visual Studio 2010:
I've tried "Dependencies..." on the csharp project and adding a dependency on mycppproject, but that has no effect.
I've tried "Add Reference..." on the csharp project and adding a reference to the cpp project, but I get a warning message 'The Target Framework version for the project "mycppproject" is higher than the current project Target Framework version. Would you like to add this reference to your project anyway?' (Yes/No/Cancel).
Clicking "Yes" produces the error message "A reference to mycppproject" could not be added."
You cannot add a reference to an unmanaged DLL.
Instead, you should make a post-build task to copy the file.
Alternatively, you can add a link to the unmanaged DLL as a file in the C# project, and set Build Action to None and Copy to Output Directory to Copy If Newer.
Visual Studio doesn't support referencing an unmanaged C++ project from a managed C# one, but MSBuild supports referencing any project from any other project.
You can manually add a reference to your project by editing the .csproj file by hand. In the file, find your existing set of ProjectReference elements (or add a new ItemGroup if you don't have one) and add the following reference:
<ProjectReference Include="..\mycpproject.csproj">
<Project>{b402782f-de0a-41fa-b364-60612a786fb2}</Project>
<Name>mycppproject</Name>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
<OutputItemType>Content</OutputItemType>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</ProjectReference>
When you perform the build, the reference will cause MSBuild to build the referenced project first. The ReferenceOutputAssembly value tells MSBuild not to copy the output assembly of the build (since the C++ project does not produce one), but the OutputItemType and CopyToOutputDirectory values instruct it to copy the output content to the referencing project's output folder.
You will be able to see the reference in Visual Studio, but you can't do much with it there.
This answer is based on a similar problem solved by Kirill Osenkov on his MSDN blog: https://blogs.msdn.microsoft.com/kirillosenkov/2015/04/04/how-to-have-a-project-reference-without-referencing-the-actual-binary/
I would follow Slaks' second answer...
[...] you can add a link to the unmanaged DLL as a file in the C# project, and set Build Action to None and Copy to Output Directory to Copy If Newer.
... followed by my comment, to differentiate between Debug and Release builds (even if is a little bit "hackish", since it requires you to manually edit the C# project file)
open your C# project's csproj file with a text editor and search for all "YourNativeCppProject.dll" occurrences (without the ".dll" subfix, so if you added pdb files as a link too, you'll find more than one occurrence), and change the Include path using macros, for example: Include="$(SolutionDir)$(ConfigurationName)\YourNativeCppProject.dll
PS: if you look at the properties (F4), VS shows you the Debug's path even if you switch to the Release configuration, but if you compile, you'll see that the dll copied to output is the release version*
Add Rederences only works for .NET assemblies, .net projects in the same solution or for COM components ( for which a manager wrapper will be created anyway... ).
the fact that in your C# code you access the C++ dll with DLLImport does not mean that Visual Studio will know from where to where the external dll should be copied.
Imagine that DLLImport is a runtime option, the path you puth in there is used at runtime to look for the dll, so you have to deploy the c++ dll yourself and make it available for the .net application, usually in the same bin folder.