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.
Related
I have added a path in VS2022 to a C++ project under project property page => public include directories. Let's call it Project A
Project A was added with add Reference as reference to C++ Project B. However, Project B does not recognize the include paths of Project A.
Do I need to set something else?
requires at least Platform Toolset v143
Previously, an older version was used.
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.
I have project A and project B in the same solution. I have installed the Microsoft.IdentityModel.Protocols.OpenIdConnect NuGet package in project A, but this updated the version of the System.Web.Http assembly in project B, this change is visible in the App.config of project B. Project A and project B do not have a relationship of any kind, but as far as I know even if they did, this should not have happened.
Change in App.config
Now here are some facts...
There is no reference to the System.Web.Http assembly in B.csproj
System.Web.Http is not found in packages.config of project B
It seems like nothing is using the System.Web.Http assembly in project B
When I go to add a new reference, System.Web.Http is not even an option, where does it come from? It is also not found in the packages directory of the solution.
Deleting it from App.config of project B does not break anything
I am aware of binding redirects (which is what is happening in App.config of project B), and so I think what happened is someone at some points has installed package A that had a dependency on System.Web.Http (eg. version 1.2), then installed System.Web.Http (eg. version 1.5) (I don't know how, since I can't seem to find a way to install it), then removed both, but the binding redirect was left in App.config.
I am basing the above paragraph on this blog post.
But why does it get updated by installing Microsoft.IdentityModel.Protocols.OpenIdConnect in a completely different and unrelated project?
Question:
Where can I find System.Web.Http on my system?
In what scenario would this whole situation be possible? What else should I check?
Is there anything else I am missing or mis-understanding?
Although I have added the System.Web.Http assembly to my project X the HttpSelfHostConfiguration type can not be resolved. And I use resharper...
The odd thing is that the HttpConfiguration works.
When I run some integration tests from project Y using static classes in project X I get a runtime exception: The file or assembly System.Web.Http, Version=5.0.0.0 can not be found etc...
Why can I not resolve the HttpSelfHostConfiguration?
HttpSelfHostConfiguration is located in the assembly System.Web.Http.SelfHost.dll and the namespace System.Web.Http.SelfHost. So you might need to add a reference to this assembly, maybe by adding the Self Host Nuget package.
If you've already added this package, the error might be related to the other errors you're experiencing regarding System.Web.Http v5.0.0.0: I've also experienced some strange behavior after upgrading a Web API project to VS2013. I could only solve this by removing the Web API Nuget packages (the error message resembled yours), deleting some remainders of old versions in the packages folder and adding the required Nuget packages anew.
Solution:
You can add reference from the NuGet Package Library.
Search for Package: Microsoft.AspNet.WebApi.SelfHost
and install it.
For those who has any confusion in adding NuGet Package Reference:
In Visual Studio Solution Explorer, Right Click References > Manage NuGet Packages
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)