I've got a C# project in my solution. When I try to build it, a different C++ project is being built first. The C++ project is not listed as a project dependency of my C# project, or as a dependency of its dependencies.
And there is no "build only" option for C# projects so I cannot tell if this is a dependency issue, or some weird bug.
Anyone able to help?
Related
I have a proof-of-concept solution that has a .NET Standard project in it. I use Paket to manage my nuget dependencies. I am able to use paket add and dotnet restore, per these instructions, to add a nuget dependency to that project. When I reopen my solution, I see that a paket.references file has been added to that project, and that a "NuGet" section has been added under the project's "Dependencies" section in "Solution Explorer".
I'm curious, how does VS2017 know what dependencies to list that "NuGet" section?
From the instructions I linked to above:
In contrast to traditional .NET projects Paket will not add assembly
references to your project files. Instead it will only generate a
single line:
<Import Project="..\..\.paket\Paket.Restore.targets" />
This hook tells the .NET SDK to restore packages via Paket's restore
mechanism. A nice benefit is that your project files are now much
cleaner and don't contain many assembly references.
I'm sure I'm missing something, but I don't see anything in Paket.Restore.targets that would tell Visual Studio where to look to find the dependency chain of the nuget package I added to the project. There are no direct references to any dependencies mentioned in the project file.
For context, I have a repo where I'm trying to add a .NET Standard project to a solution that is full of .NET Framework projects. I'm running into an issue where paket add seems to correctly create a paket.references file for the new project, but dotnet restore doesn't seem to be causing the project references to update, resulting in my project not having a reference to the nuget dependency I'm trying to have it reference. I'm having trouble creating a reproducible example (my proof-of-concept seems to be working fine), so I'm trying to better understand how this infrastructure works to help with debugging.
I'm using visual studio 2010, and its a C++ solution with multiple projects. I have project A which has reference to project B(Properties->Common Properties->Framework and References). Project C references project A.
Now the build order is B->A->C. C now indirectly references B, is it required that we should manually add Project B as reference to project C?
I want to make sure that when project C is built project B should automatically be built if any changes were made to it and it is not rebuilt yet.
Building your Solution should always build Projects that have changes.
A circular dependency is created if you try to make B->A->C->B. You can have circular dependencies in VS but the build order must be managed manually. See this post.
If a Project references an assembly and not the Project that builds that assembly then VS does not build the dependent Project. If the Project references the Project that builds the dependent assembly then any changes to the dependent Project are built before the target Project. This is the default behavior in VS. That behavior can be changed or managed using the 'Build Dependency' dialog.
I have one .NET UI project and another managed C++ projects.
Unless and until I build C++ projects; .NET UI project keep showing the build errors all the time. This simply clutters the Error Window. Isn't there any option which will allow to manipulate what could be shown in Error Window?
Most probably there is no dependencies set up for the projects in your solution, or dependencies are set up incorrectly.
You probably should make UI project dependent from your other projects. This way, the UI project will be built after other projects.
How to: Create and Remove Project Dependencies
Is it possible to tell VS not to recompile some projects every time and use already compiled dll-s instead?
You can exclude any project from building in Configuration manager. Just unselect desired projects in Build column. You still will be able to debug those projects.
Instead of project references, you can add the compiled DLLs as references.
Any such referenced project will not rebuild if not changed.
However, since the references will now be to DLLs, you need some strategy to keep them synchronized and up to date with your code.
As I understood your question, you have a solution with multiple projects and you seem to have dependency of some of them on some other.
VS will always compile all the "loaded" projects. But when you add a reference to a project, add it directly to a (preferred) DLL assembly file, and not to one of the projects. This way the other project will be compiled but you are referencing the same DLL assembly over and over. Since if you reference the project, the output of the project is always what you reference actually.
I have a Visual Studio 2008 solution with two projects in it. A C++ DLL and a Csharp application.
The Csharp application uses [DllImport] to access the functions in the DLL, and has a dependency set on the DLL.
For some reason, setting the dependency isn't sufficient to cause VS to copy the DLL to the build path of the app. So the app project has a post-build event which causes the DLL to get copied. (If anyone knows of a cleaner way of doing this, please let me know!)
The problem I have is that when I make a change to the DLL code, then attempt to run the Csharp application in the debugger, VS2008 fails to realise that the DLL must be rebuilt (and re-copied).
I have to force a re-build of the Csharp application (ie by explicitly choosing build, or by "touching" a .CS file).
Does anyone know how to tell Visual Studio to do the right thing?
Edits:
I am using project dependencies. They aren't working correctly.
I am using a post-build event to copy the DLL across.
The issue is that, if you simply choose to debug the application, Visual Studio fails to recompile the changed C++ project, despite the fact that there is a dependency in place.
I know the dependency is working, because if I choose "Build" (as opposed to "Debug") the C++ DLL is built.
"Build" and "Debug" do different things. In Tools - Options - Projects and Solutions - Build and Run, there is a checkbox "Only build startup projects and dependencies on Run". This is checked by default. So, if VS isn't recognising the DLL as a dependency, it won't build it when you choose "Debug".
I don't have VS to hand (only Express), but you could try adding the C++ DLL as a reference rather than a dependency.
Hmm... so I haven't done this exact thing before but I just threw together a C++ lib project and a C# winform project in the same solution. I right-clicked the solution, chose Properties and then under Common Properties->Project Dependencies, I made the C# one depend on the C++ one.
When I make a mod to the C++ one, it will ask me if I want to rebuild the C++ one. There's a "Don't ask me" checkbox too.
Maybe my test is different than your situation, but it seemed to work when I did that.
Hope that is some help.
Assuming the DLL project isn't used in another solution, why not put the post-build event on the DLL app project, so it is always copied?
I've not tried, but can't you do this with the build order?
I have experienced this same issue with applications that have DLL project dependencies. It seems to me that the problem is that Visual Studio only launches the post-build event if it has to recompile something in the Application's project. So, if you modify the DLL source without modifying any of the headers that the Application includes, then the Application is not recompiled because from it's perspective the DLL is the same. Since the application is not recompiled, the post-build event is not triggered. So, the Application is left with out of date DLLs. I have yet to come up with a good solution to this problem.