Context
There are two .NET Core 3.1 projects a Visual Studio 2019 16.7.2 solution.
The class lib project has a package dependency on NuGet package AutoMapper 9.0.0
The web application project has a project dependency on the class lib.
Runtime I got the "Could not load assembly AutoMapper 9.0.0.0". My first thought was some version mismatch but all projects set to .NET Core 3.1.
I've investigated, and in the web application project /bin folder there is no AutoMapper assembly.
So I've investigated further, and it seems the web app project somehow ignores this implicit dependency, see picture.
What I've tried so far:
I've tried to clean all, then rebuild.
I've tried to exit, then restart Visual Studio
Question
What am I missing here?
For Kirk's comment:
<ItemGroup>
<ProjectReference Include="..\Benedetto.Abstractions\Benedetto.Abstractions.csproj" />
<PackageReference Include="AutoMapper" Version="9.0.0" />
<PackageReference Include="IdentityModel.AspNetCore.OAuth2Introspection" Version="4.0.1" />
First, Glad to know that you have solved the issue. To add an answer here for other community members handle similar issues.
Solution
clean all nuget caches first or just delete all nuget caches under C:\Users\xxx(current user)\.nuget\packages
close VS Instance, delete bin and obj folder
use nuget xxx\xxx.sln command line to restore nuget packages
then restart project to fix the issue.
Related
I am aware there are multiple questions on this topic already, but they all seem outdated. To clarify, I am using the "new" VSIX manifest format, and trying to follow the official instructions here: https://learn.microsoft.com/en-us/nuget/visual-studio-extensibility/visual-studio-templates
I have one project template and a couple of item templates that go with it. They all depend on deploying a NuGet package that should come bundled locally with the VSIX. I have examined the resulting VSIX file and all the files seem to be in the right place:
The project template has the required XML for declaring which packages to install:
<WizardExtension>
<Assembly>NuGet.VisualStudio.Interop, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</Assembly>
<FullClassName>NuGet.VisualStudio.TemplateWizard</FullClassName>
</WizardExtension>
<WizardData>
<packages repository="extension" repositoryId="VsixID.etc.etc">
<package id="Rx-Linq" version="2.2.5" />
</packages>
</WizardData>
The repositoryID matches the ID attribute in the .vsixmanifest file.
There is an individual Asset entry for each package, with the form:
<Asset Type="Rx-Linq.2.2.5.nupkg" d:Source="File" Path="Packages\Rx-Linq.2.2.5.nupkg" d:VsixSubPath="Packages" />
I have removed all packages.config and all the package references from the .csproj file installed by the VSIX (and even from the VSIX project itself just for good measure).
I have inspected the output VSIX and there is indeed a Packages folder in the VSIX containing all the .nupkg files. This folder is indeed unpacked and copied into the Visual Studio Extensions folder.
Despite all this, when I create a new project with the template, VS displays an error message saying: Failed to restore package from C:\users\<pathtoextensions>\Packages.
The thing is, the .nupkg files are actually present in the exact folder that the error message refers to.
I have been searching this for days and I can't seem to find any reference to best practices that actually work. It seems like these VSIX manifests are geared towards the legacy packages.config way of doing things, and there are discussions about how to extend them to use PackageReference instead.
Can anyone give any advice at all at how we are supposed to proceed going forward? Are packages not supposed to be deployed with the VSIX anymore? Are we supposed to just fill in the project with PackageReference entries and just let the user resolve them manually?
I feel like I am missing something fundamental here and any insight would be extremely valuable.
Update: I have also opened an issue on the NuGet github repository, as this is clearly a problem with the PackageRestore feature when restoring packages stored in a VSIX installer. Everything else mentioned in this question is working as intended and expected, except the package restore.
How do you actually include NuGet packages in Visual Studio Project
Templates VSIX targeting Visual Studio 2019?
Actually, there is no way to specify in a VS project template project that nuget packages can be used both using packages.config and PackageReference. Only two project templates of nuget management types can be created separately.
I have an easy way and since you have some issues with PackageReference format, you can try this funtion:
PackageReference
1) add these reference node in projecttemplate.csporj file:
<ItemGroup>
<PackageReference Include="Rx-Linq">
<Version>2.2.5</Version>
</PackageReference>
</ItemGroup>
2) When you create a project by this project template, please check these two options and VS will automatically read xxx.csproj and then recover the corresponding nuget package based on the information in it during build process.
Note: also make sure that the nuget url is checked and can be access under Package Source.
packages.config
In additon, for packages.config, you can just create a file named packages.config and then add your nuget info into it:
1)
2) add these into projecttemplate.csproj file:
<ItemGroup>
<Content Include="packages.config">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</Content>
</ItemGroup>
<ItemGroup>
<Reference Include="Rx-Linq, Version=2.2.5, Culture=neutral, PublicKeyToken=eb42632606e9261f, processorArchitecture=MSIL">
<HintPath>..\packages\Rx-Linq.2.2.5\lib\net472\xxxxxxx.dll</HintPath>
</Reference>
</ItemGroup>
Note: if this nuget package has dependencies, you should also add them(above steps) into packages.config and xxxx.csproj file. This funcution is a little more complicated than yours but it works. So, I recommend that you use PackageReference format.
More info you can refer to this similar issue.
How should I reference to another project A from project B in the same solution?
What do I gain and what do I lose if I:
Add the reference to project A as a project reference.
Install the NuGet package of project A in project B.
Things that would bother me are build dependencies, versioning..?
Or does this totally destroy the purpose of a solution?
Project reference VS NuGet
Project reference or NuGet is a very common problem in our development process, we need to choose which one to use based on our actual situation.
For example, if the referenced project A is modified frequently during the development process, we recommend to use Project reference. Because if you use nuget, you have to rebuild the referenced project, recreate the nuget package, reinstall that nuget package to the project B, even you have to publish it to the server. This will bring a lot of unnecessary work and we often forget to update our nuget package after we modify the referenced project A. If you use the project reference, you will not have these problems. The modified referenced project A will be update automatically before we build the project B.
On the other hand, when we share our referenced project A out of solution, or share that project to others, nuget will be a better choice. It has more portability.
So the project reference will be recommended when you reference to another project A from project B in the same solution, the nuget is more appropriate when share the reference project out of solution or share project to others.
Besides, there is a Visual Studio extension NuGet Reference Switcher, which which automatically switches NuGet assembly references to project references and vice-versa.
Hope this helps.
With the first approach, you gain in simplicity, since you don't need to generate a new version of the ProjectA nuget package, every change you make in it (i.e. ProjectA.nupkg).
However, with the second approach, you gain in portability, since you can easily share the same nuget package with other projects / solutions.
Personally, I create nuget packages only for projects whose goal is to share with other solutions. (E.g. libs and frameworks).
Hope this helps you decide!
Nowadays with the new csproj format the you can use both at the same time (if you have both projects in the same solution).
In your example, you could reference project A from project B as a project reference. Then, if you want to release project A as a NuGet package you just need to add the following tag to it's csproj inside a PropertyGroup:
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
The plot twist: If you want to release project B as a NuGet Package too just add the GeneratePackageOnBuild target - MSBuild will set projectA.nupkg as a dependency in projectB.nupkg.
This way you can work internally with your projects while at the same time release them as packages to third parties or other teams.
You could use both: project references during development (faster), and package references during production.
In your .csproj project file:
<ItemGroup Condition="'$(Configuration)'=='Debug'">
<ProjectReference Include="../../../Library1/Library1.csproj" />
<ProjectReference Include="../../../Library2/Library2.csproj" />
</ItemGroup>
<ItemGroup Condition="'$(Configuration)'!='Debug'">
<PackageReference Include="Library1" Version="1.0.0" />
<PackageReference Include="Library2" Version="1.0.0" />
</ItemGroup>
In development: project compiled in debug mode, so the project reference will be used.
In production (CI server, docker container): project compiled in release mode, so the package reference will be used.
I am creating couple of .NET Standard 1.6 libraries that I want to publish as Nuget packages. They share a common libary that is a 3rd project in the same solution as the first two. The shared library has no value by itself, but I am assuming that if I want people to use both of these two libaries in the same project I should publish the shared library as a Nuget package as well. If I don't I am worried about multiple copies of the same shared library "colliding" or not properly warning when there are version mismatch issues.
Am I correct that the shared library needs to be a Nuget package as well? Is there a way to reference the shared library as Nuget package, but use is as if it was a project reference when developing / debugging the 2 main libraries in this solution? If I had to publish to Nuget.org and wait for the package be propagate through the Nuget.org system before using a changed version in a debug session that is REALLY going to slow down development. Note that these are .NET Standard projects. I found How to reference related projects in the same solution when Nuget packages are the required output but that doesn't seem to work with .NET Standard (getting errors during pack) and I am also not sure if .NET Standard not using nuspec files anymore also would cause a problem.
I am also not sure if .NET Standard not using nuspec files anymore also would cause a problem.
The .NET Standard still using .nuspec files, and using old school nuget pack and a .nuspec will resolve this issue.
As per document dotnet pack:
NuGet dependencies of the packed project are added to the .nuspec
file, so they're properly resolved when the package is installed.
Project-to-project references aren't packaged inside the project.
Currently, you must have a package per project if you have
project-to-project dependencies.
So, to include project-to-project references in NuGet packages, you need manually maintain a .nuspec file and add dependencies. You can refer to the Create .NET Standard packages with Visual Studio 2015 for detail info.
Besides, dasMulli has provided a simpler way to do this by involving adding and hooking up a custom target :
<Project>
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);IncludeP2PAssets</TargetsForTfmSpecificBuildOutput>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\testprivatelib\testprivatelib.csproj" PrivateAssets="All" />
</ItemGroup>
<Target Name="IncludeP2PAssets">
<ItemGroup>
<BuildOutputInPackage Include="$(OutputPath)\testprivatelib.dll" />
</ItemGroup>
</Target>
</Project>
The source code comes from: "donet pack" is not including project references
I'm testing migration from VS 2015 to VS 2017 for a .NET Core / TypeScript project.
The build fails in VS 2017 with this error in Microsoft.TypeScript.targets:
MSB4064 The "PreferredUILang" parameter is not supported by the "VsTsc" task. Verify the parameter exists on the task, and it is a settable public instance property.
The version of TypeScript in VS 2017 is 2.1.5, however, I have already installed the 2.2.1 SDK for Visual Studio 2015.
I've also noted that there is no 2.2+ SDK release for Visual Studio 2017 yet.
Could this be causing conflicts? Is this something I can resolve now or do I need to wait for an update to the TypeScript SDK for VS 2017 to reach 2.2.1+?
Any help in this area appreciated!
This might be a bit of crude solution to the problem but we simply went through the "Microsoft.TypeScript.targets" file and removed PreferredUILang="$(PreferredUILang)" from any <VsTsc ... > nodes, we had a look into the Typescript task dll and it seems that it does not have a PreferredUILang property.
It is possible that the task once upon a time did have such a property but was removed and Microsoft have forgotten to update the targets file, I'm not sure but this seems to be working for us at least.
Please make sure you backup your "Microsoft.TypeScript.targets" file before editing.
I have same problem here in VS2015 Update 3 and I also fixed the Microsoft.TypeScript.targets, as suggested by ginja, but as I don't like to hack the nuget packages I went deeper in the issue.
The real problem is that when you add/upgrade the typescript nuget package, you have to manually remove the imports to the machine-wide targets and props. having both leads to unknown load order or targets/tasks, which would manifest in such errors.
So the approach I used is:
Uninstall from the project the nuget packages "Microsoft.TypeScript.Compiler" and Microsoft.Typescript.MSBuild"
Close VS (to guarantee the real clean of such package)
Edit you .csproj file commenting out the imports to the machine-wide targets and props: (all <Import Project="$(MSBuildExtensionsPath32)\Microsoft\...
Restart VS, open the project and add again the nuget packages for Typescript. This point correctly updates your .csproj with the correct imports and configuration of the TypeScript compiler.
Just for a clean safe: restart VS.
removing following lines from CSPROJ solved problem for me
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props')" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\WebApplications\Microsoft.WebApplication.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\WebApplications\Microsoft.WebApplication.targets')" />
to edit csproj file
Right click the project in Solution Explorer.
Select "Unload project"
Project is now unloaded.
Right click the project again and select
"Edit blah.csproj"
Make your changes and save them.
I need to use some classes from another project. How can I just import or create a reference to that project in Visual Studio?
Right now if I use "Add reference" in Visual Studio, I get the error:
".NET Core projects only support referencing .NET framework assemblies in this release. <br/>
To reference other assemblies they need to be included in a NuGet package"
.NET Core works with dependencies via NuGet.
If your projects are in the same solution, then yes, you can add a reference using the Visual Studio UI ("Add reference" command). A background reference will be added as a NuGet package.
Manually you can do this by adding <ProjectReference> section to the .csproj file:
<ProjectReference Include="..\ClassLibrary1\ClassLibrary1.csproj" />
Otherwise, you should pack your project into a NuGet package (use the dotnet pack command) and then add it as other NuGet packages.
If you do not use any public NuGet sources, you can host your own NuGet feed.
You have the next error:
".NET Core projects only support referencing .NET framework assemblies in this release.
To reference other assemblies they need to be included in a NuGet package"
Because you are trying to add a .NET project to a .NET Core project or wise versa. Look into this issue for more details:
If you're using netcoreapp then you cannot use .NET 4.x
assemblies/packages
If you're using net4xx then you can use the frameworkAssemblies
section of project.json to reference DLL files that are installed by
.NET Framework (the stuff in the GAC)
I had a .Net core project and i wanted to create another project for services in my solution. After adding the project I added the reference as follows:
Right click Dependencies in your solution.
Select Add Reference option.
In the next window, in Projects dropdown select the project you want to add.
Alternatively, you can add a reference by editing the csproj file of the project in which you want to add the dependency/reference. Open the file and add the following:
<ItemGroup>
<ProjectReference Include="..\PATH\TO_YOUR_NEW PROJECT.csproj" />
</ItemGroup>
Hope this helps someone.
You can add reference by adding your project name in csproj file. if your project in same solution
<ItemGroup>
<ProjectReference Include="..\projectName.csproj" />
<ProjectReference Include="..\ProjectName2.csproj" />
<ProjectReference Include="..\ProjectName3.csproj" />