I have a solution with multiple projects.
The solution has projects in both C # and VB.
The solution has SDK-style and non-SDK-style projects.
I uses VS2019. It builds the solution without any errors.
My build server is using MSBuild from VS2019 build tools. It founds CS0246 errors in my solution.
Examining the code shows that the problem is the missing project reference. Project dependency hierarchy is shown below:
A - SDK-style C# project
|
+-> B - Non-SDK-style VB project
|
+-> C - SDK-style C# project
The code from project A uses classes from project C. But project A doesn't have project C in its ProjectReference list. It is an error without doubt.
But why VS2019 does not detect CS0246 error?
What should I change in my VS2019 so that it gives me exactly the same build results as the build server?
Version of MSBuild is the same 16.8.2.56705 on build server and on my PC.
Actually, I did not face the same issue in my side.
In my test project,
Project A(a new-sdk style net472 console project)which has a ProjectReference to Project B(a vb net framework 4.7.2 class library project) like this:
Use ProjectReference:
<ItemGroup>
<ProjectReference Include="..\ProjectB\ProjectB.vbproj" />
</ItemGroup>
While Project B also has a ProjectReference to Project C(new-sdk net472 class library project):
<ItemGroup>
<ProjectReference Include="..\ProjectC\ProjectC.csproj">
<Project>{bf3ad507-ed99-486a-b90d-51d8acc25dfc}</Project>
<Name>ProjectC</Name>
</ProjectReference>
</ItemGroup>
In my side, I also uses the function from Project C into Project A and it builds with any errors.
In fact, Project A can obtain the content of Project C through the transfer relationship. The build order is C, B, A. A first visits B to find the method of C. When the reference to C in B is read, there is access to the project of C, so the method of C is obtained. Therefore, there is no need for A to have a reference to C. As long as the order of the dependent layers is correct, there will be no problem.
Then, I passed the whole solution to the build server and then it works well.
So please try the following suggestions:
1) make sure that your build tool has installed the related workload such as .NET Desktop build tool,Net Core build tool, also the related Net Framework version.
2) delete every project's bin and obj folder on the build sever
3) use Build Tool, first restore and then build.
cd xxx\xxx.sln
msbuild -t:restore,build
If your VB project has other nuget packages, you should use nuget restore additionally:
cd xxx\xxx.sln
nuget restore
msbuild -t:restore,build
Besides, if it does work for your issue, please share a small sample here which will help us investigate this issue more efficiently.
Update
Project A:
using System;
using ProjectC;
namespace ProjectA
{
public class Class1
{
static void Main(string[] args)
{
Test te = new Test();
Console.WriteLine(te.Tec(3, 5));
Console.WriteLine(te.Test1());
}
}
}
Project C:
using System;
namespace ProjectC
{
public class Test
{
private int a, b;
public int Tec(int a,int b)
{
return a + b;
}
}
}
Project A references Project B , B references C. And A uses the function from C.
Screenshot
I moved the solution into build sever, and then delete .vs, every bin and obj folder and then run these commands, no error occours.
Maybe there is something wrong with your build sever. Please click Repair from VS Installer for the build tool. Or just reinstall build tool.
It seems that the issue was fixed in VS 16.8.4:
Issued Addressed in this Release of Visual Studio 2019 version 16.8.4:
Transitive project references are now respected when a PackageReference projects >references packages.config projects with PackageReference dependencies.
We had the same issue and now it works fine.
Related
I have two project A,B. Project B has a reference to project A (B -> A). Project A has Thinktecture.IdentityServer.Core package which has dependency on Thintecture.IdentityModel and a simple class which make use of Thinktecture.IdentityServer.Core:
public class Class1
{
public UseThinktecturecoreInOrderToCopyDll()
{
// wrapper for Thinktecture.IdentityModel
Thinktecture.IdentityModel.Web.ProtectionMode wrapper
= Thinktecture.IdentityModel.Web.ProtectionMode.MachineKey;
}
Thinktecture.IdentityServer.Repositories.ICacheRepository repository;
}
Now when I build solution the Thintecture.IdentityModel is copied to project A, but is not copied to project B. But when I update packages then Thintecture.IdentityModel dll on next solution build is copied to project B. Can anyone explain this behavior? How can I force copying without updating packages? why packages update solve the problem?
I have this problem on more complex solution. I know it is possible to solve the problem by building project A separately but I'm not satisfied with that solution as it require to keep building the project A separately.
*Also I do not like a solution where I have to add reference to each project which I'm indirectly using (for Thinktecture.IdentityModel).
You have problem with references in your NuGet packages. Your Thinktecture.IdentityServer.Core has a reference on Thintecture.IdentityModel 3.4.0 and you have installed Thintecture.IdentityModel 3.0.0. So visual studio doesn't copy invalid Thintecture.IdentityModel 3.0.0 reference. When you update your Thintecture.IdentityModel to version 3.4.0 it starts working because reference is valid.
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.
We have a visual studio package (VS Package) that references a class library project (Project A). Project A in turn references another class library project (Project B).
So the dependency structure looks like this: VS Package > Project A > Project B
All projects exist inside the same solution and the dependencies have been set up as proper project references.
If I build the package in visual studio and look in the bin/Debug folder all necessary assemblies are there including Project B's. However when the package is deployed, only Project A's assemblies are present and Project B's are missing. How do I tell visual studio to include the indirect dependency of Project B in the package?
This MSDN document suggests that "By default in a multi-project solution, if a project that outputs to a VSIX package includes a reference to another project in the same solution, it includes the dependencies of that project."
However I am finding that this is simply not the case.
My question is very similar to this one except that I am having trouble with the main project assembly and not the localization satellite assemblies. The answer in this other post does not work for me because it seems to only work for satellite assemblies.
Is there some other Output Group that I can specify to direct the package to include indirect dependencies as well?
Thanks for looking.
The simplest thing to do in this particular case is reference Project B from the VSPackage project and set the "Reference Output Assembly" property to False to avoid introducing a compile-time dependency.
I had a similar problem: My VS Package project referenced another VS package project (~Project A) which in turn referenced a bunch of other projects (~Project B) containing the meat of our extension.
Inspired by this answer: VSIX package doesn't include localized resources of referenced assembly, I added 'BuiltProjectOutputGroup;BuiltProjectOutputGroupDependencies;GetCopyToOutputDirectoryItems;SatelliteDllsProjectOutputGroup' to the Output Groups Included in VSIX property of the reference from VS Package to Project A.
This had the effect of dropping all the dependency DLLs in the ...\Debug\ folder for my VS Project, but they still didn't get included in the VSIX.
Finally I went and added the BuiltProjectOutputGroup;BuiltProjectOutputGroupDependencies;GetCopyToOutputDirectoryItems;SatelliteDllsProjectOutputGroup flags to all the references from my Project A to each of my Project Bs - then they all got included in the VSIX.
(BTW this is with with Visual Studio 2013, but it doesn't seem to have change much since 2010)
I'm working in a project for a customer where one solutions has 3 projects.
Project A is the base, then project B depends on A, and project C depends on B. By the way, project C is the application, A and B are class libraries.
Usually, I can make a change in project A without the need of manually recompile B and C because Visual Studio does it automatically for me.
However, in this environment (after downloading the solution via Ankh SVN), the dependencies are somewhat not recognized when executing. I'm forced to manually recompile the dominant projects of the dependency hierarchy.
Why is this happening? and how to solve it?
Thanks!
Make sure you added the references of project B and project C as a project and you didn't add the project output as an assembly reference.
I have a c++ project in VS2010 and a c# project that is to consume this c++ project output (it uses it for p/invoke). I was thinking that I could ensure that the c++ project was build before the c# project by editing the "Project dependencies..." in the solution but this does not seem to have any effect, the build on my buildserver does not respect this setting (I'm using TeamCity to bootstrap an MSBuild file that builds the entire solution file)
I think this used to work, has anything changed with VS2010? Or should I declare the dependency in another way?
SOLUTION: The trick was to hand-edit the csproj file outside VS2010 and add a section like this:
<ProjectReference Include="..\CobraLib\CobraLib.vcxproj">
<Project>{598506DA-91DA-4F25-948D-A14CB16ABEBA}</Project>
<Name>CobraLib</Name>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
That made the build server process my projects in the correct order. Only caveat is that VS2010 displays an error on the project reference ("not a .NET project") but otherwise things are working as I intended