There is a project that implements a dll. There is another project that uses that dll, let's call it "calling" code. For both there is available the source code.
Is it possible to easily integrate into the calling code the source of the dll in order to change/debug together both and then to separate again to build exe and dll so that one can run the exe which will call the dll?
Now I am doing in such uncomfortable way : I add the source of the dll to the project of the calling code, modify, build everything and test/debug.
When everything is ok I remove dll source from calling project, cut and paste it into the dll project. and build the dll. Finally I add the reference to the dll into the calling project, then build. I guess there is a better way.
Related
I have a C++/CLI project with multiple source files in it now. I have a separate c# project which i added as a reference in the C++/CLI project and used a method from the c# code in one of the .cpp files.
When i update the c# code, what i have found is that the c++/CLI project is fully rebuilt, even source files which don't reference the c# code. MSBuild logs messages similar to the below in the output
Interface.cpp will be compiled because $somepath\Helper.dll was
modified at $time.
I initially expected it to rebuild/build only the specific c++ file i referenced the project in. Is there anyway to work around this ?
Edit :
I wrote the specific c# method onto a separate c++/cli project and tried referencing that in my original c++/cli project. With this approach, my original project gets rebuilt only when something in the header file changes like adding a new method.
Interface.cpp will be compiled because $somepath\Helper.dll.metagen was
modified at $time.
If I change the body of an existing method in the cpp file, the rebuild doesn't happen. Would love to achieve that same behavior when referencing the c# dll.
I've created a simple library project to use in another monotouch project. When ProjectA References LibraryProjectB.csproj, it works perfectly. However when ProjectA references the .dll created by LibraryProjectB (LibraryProjectB.dll), I get a couple of compiler errors such as "Compiler Error, method __ does not exist"
Why does directly linking the project work while the DLL that the project creates causes errors?
This is because your build steps get out of order when you do this. So you add a method to your library, and use it in your project. Well, your app could get built first--and then not be able to reference the new method.
You need to reference the project directly.
At the moment I have added and referenced another project to my main solution. It works, but then I need the separate dll that is compiled.
How can I reference another project without the need for a separate dll that I have to distribute with my final exe?
A C# class project in a Visual Studio solution always compiles to an assembly, so adding a project reference will inevitably mean that your executable references the assembly built as a result of compiling the other project. If you don't want to distribute the separate assembly with your executable the only thing you can do is to ILMERGE the assembly into your executable as a part of your deployment build process,
You can't. The way .net works is to load an additional assembly and using its meta data the classes inside that. If you are attempting to have a set of classes that you refer to by source similar to the way c++ uses header files you will have to import those files into your project.
This sounds like you're trying to statically compile a library. This is not (easily) offered by .NET without manually creating and merging assemblies.
I have a C# project which references a DLL (call it external DLL) which comes with another application. When I build my project, due to the reference, the external DLL gets automatically added to my project output. And when I run my project it loads the external DLL from my project folder.
The other application, which the external DLL belongs to, is developed by another team and the DLL is regularly updated. I don't want to package their DLL with my project. Instead I would like to have my project load their DLL when executed -- rather than pick the DLL copy from my project's folder.
Now I know that this is possible through reflection. I know that I can do an "Assembly.Load" and pick the DLL. But because I use the types from the external DLL all through my code, I would like the code to be statically type checked.
Here's what I would like:
Be able to compile my project by referencing the external DLL and thus get static type checking.
When the project is run, the external DLL is picked up from the other application's folder and not the copy of the DLL which is in my project's output folder.
Is there any way to solve this problem? Is there some middle ground between adding a reference and using reflection?
The most immediete solution to your problem is to change the properties of the reference. There is a setting called Copy Local. Set that to false and it'll stop copying the DLL to your project's output. You can access the properties of the reference by expanding the references folder in your solution, right-clicking on the reference in question, and clicking properties to open the properties pane.
The fact that Visual Studio copies the DLL to your project's output folder at build time doesn't really matter to the .Net Framework at runtime. All that matters is that the assemblies you reference are available to the framework either in the paths it searches or in the global assembly cache.
I'm trying to add a generated COM interop assembly project to my solution, and the only solution I could come up with feels really nasty.
I created a .net dll project, removed all .cs files from it and then created the following post-build event:
call "$(DevEnvDir)..\tools\vsvars32.bat"
midl.exe $(ProjectDir)relative-path-to-my-idl\MyComName.idl /tlb MyComName.tlb
tlbimp.exe /keyfile:path-to-my-key\k.snk MyComName.tlb
Essentially, I first create an empty DLL, then overwrite it with a real interop DLL. And there's no dependency management here - it's created every time.
Is there a better way to do this?
The MIDL compilation can be handled by making the COM interop project a managed C++ project (instead of a C# project) then adding the idl and h to the project as regular source files.
You can overcome the dependency problem by using MSBuild tasks directly instead of a PostBuild batch file, which line up nicely with the MSBuild dependency system.
However, why are you generating the file manually from an idl? When I need COM interop, I just import it and put the generated assembly (*.Interop.dll) into version control. This way, you always have the version you need and it's already ready to use, and Visual Studio can find the interop DLL before the first build, i.e. Intellisense is there right from the beginning.
Now some people won't like to check in a binary file, which I typically agree with, but well, if it works... :)
Of course, my method won't work if building the COM server is part of building the solution. In this case, just try to put the generation into the MSBuild script to get rid of the dependency thing, unless Visual Studio accepts a reference to a solution-internal non-.NET-COM project.