I have two C# solutions (let's say A and B). Both reference a common C# library, which is included in both solutions as a project reference. This project itself references (as a project, not DLL) another library (managed C++) which is ALSO referenced by the two top-level solutions.
Whenever one project builds successfully, the other says that the C++ library has changed and needs to be reloaded. When I do so, the C# library reference complains that it can't resolve a namespace from the C++ library. If I delete and re-add the reference to the C++ library in the C# library, the solution builds fine, but now the OTHER solution will have the same problem, and so on.
What am I doing wrong? I believe I should be able to have this sort of reference setup without problems.
Right click the Solution and select Properties. Then select '...Project Build Order'. I assume we want the C++ project to build first?
Check the Solution Properties/Common
Properties/Project Dependencies and
make sure all the Depends On are set
right.
Is there a possibility to move all the C++ project references to the common C# library? That way project A and B just need to reference the common project.
Related
I just came across this scenario and thought I'd share it in case it saves you some time.
I have a fairly large solution in VS2017 and have a shared project that contains some common code such as enums.
I just tried to add my shared project to another project (right click project, add reference and go to shared Projects section) and noticed that the shared projects was empty. It wasn't giving me the shared project as an option.
See my answer below...
After a bit of digging it dawned on me that my shared project is C# whereas the project I was trying to add it to was VB.Net.
Obvious when you realise it, but I was still thinking of a shared project compiling to an assembly (dll) which could be referenced from VB.Net or C#. Whereas a shared project should be thought of more like a C++ include. Shared projects simply insert the source code into the recipient project and can only be used with projects of the same language.
I have two separate C# projects,
A C# project is only used as a dll reference
A C# project with 1st project as dll reference.
Now I need to clean up the old methods of 1st project which is used as a dll reference.
How can I find the functions/ methods that I am actively using/ calling from the 2nd to 1st project.
I would comment out the Using reference to Project 1, then see which lines generate compile errors. That's where the references are used.
If you use Visual Studio, you can find them all if you install Resharper:
Expand the References and choose Find code Dependent on Module
I have two C# projects in my Visual Studio solution. Project B needs to reference code in Project A. Both projects need to be compiled to dll's and then used in an application.
In Project B I can set a reference to project A and that allows things to compile. But when I actually use the resulting dll's in my application it throws a missing assembly reference error.
My current solution is to tell Project B to reference the bin/debug/ProjectA.dll. Everything works when running the application with this configuration. But this solution has a number of problems. For instance, any code written in Project A that B relies on wont be visible to B until A has been rebuilt. And building the solution relies on A being built first.
Is there a way that I can add a reference to Project A but have the resulting dll built so it looks for the ProjectA.dll reference and not the project itself? I expect there is, but my google searching has resulted in no answers.
For instance, any code written in Project A that B relies on wont be visible to B until A has been rebuilt. And building the solution relies on A being built first.
This is not a problem, this is, in my view, a benefit. As you are guaranteed to not be able access functionality which is not there. In case of a new functionality, one may say, it's not a big deal: I can not find it, got an exception/error so I know something went wrong. But what about updated code ? In this way you are guaranteed that B will use only most updated version of A.
Is there a way that I can add a reference to ProjectA but have the resulting dll built so it looks for the ProjectA.dll reference and not the project itself?
You may simply implement post-build event on your project A which copies it and all dependent DLLs in some predefined central location, where B.dll will be copied too. If your B.dll depends on A.dll, OS, following default behavior, will search for A.dll in the same folder where B.dll is, for first, before checking %PATH% variable content.
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.