I have a standard VSIX project taking a project dependency on a class library project in the same solution. Everything was building just fine until I switched the class library to the new VS2017RC simplified csproj. The class library builds fine (my dotnet SDK is 1.0.0-preview4-004233), but when trying to build the VSIX I get:
error MSB4057: The target "BuiltProjectOutputGroupDependencies" does not exist in the project.
This obviously looks like an incompatibility with a traditional VSIX csproj expecting something from dependent projects that the new csproj doesn't provide.
Has anyone bumped into this or have any advice on working around it? I'm going to look into removing the project reference and manually referencing the output DLL.
As a related side note, it's unclear which output DLL the VSIX would select from the class library, as the new csproj supports multiple target frameworks.
As stated on the GitHub issue, here's a workaround:
Unload the VSIX project.
Right-click and edit its .csproj file.
Find the <ProjectReference> to the project which started causing the issue.
Add the element <AdditionalProperties>TargetFramework=net452</AdditionalProperties>, using the correct .NET Framework version you target in the referenced project.
Reload and rebuild the VSIX proejct.
I believe you may be encountering the same issue I had when I tried to reference my Visual Studio Extension from a .NET Standard library that was targeting multiple frameworks. There is a GitHub issue dotnet/sdk#433 about it.
What I had to do was remove my other targets. In my case, I had:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netstandard1.3;net46</TargetFrameworks>
</PropertyGroup>
...
</Project>
And I had to modify it to only target netstandard1.3 (since it is compatible with .NET 4.6 according to the .NET Standard chart) and my VSIX targets .NET 4.6.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard1.3</TargetFramework>
</PropertyGroup>
...
</Project>
Related
I've started a new .NET 7 project in Visual Studio 2022. The template I used was "ASP.NET Core WebAPI". The project turned out to look like this in the solution explorer:
I can see that there is a dependency upon a series of DLLs in the folder "C:\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\7.0.2\ref\net7.0". When I browse to this folder and grab, for instance, the "Microsoft.AspNetCore.Http.Abstractions.dll" assembly I see its version as 7.0.22..... which makes sense.
What is weird is that when I click "Manage NuGet Packages" on this project I see absolutely no NuGet package already installed. It looks like this dependency mechanism is something independent of NuGet.
Now I want to create a class library that will encapsulate some common functionality I'd like to share across the projects but it needs to read data from the HttpContext class, which is defined in the "Microsoft.AspNetCore.Http.Abstractions.dll" file. So how should I add this dependency?
Adding it through "dotnet add package Microsoft.AspNetCore.App" command on the class library projects seems like a waste of resources as it adds the entire bundle of dlls and I only care about .Http.Abstractons.dll and it's direct dependencies.
Plus, when I ran the command Visual Studio complained with the warning:
NETSDK1080 A PackageReference to Microsoft.AspNetCore.App is not necessary when targeting .NET Core 3.0 or higher. If Microsoft.NET.Sdk.Web is used, the shared framework will be referenced automatically. Otherwise, the PackageReference should be replaced with a FrameworkReference".
Adding the dll through NuGet worked as Visual Studio was not complaining any more but the version of assembly added was 2.2.0 and not 7.0.2 as in the dotnet package. So technically, the HttpContext referenced in one projects is a different thing to the HttpContext referenced in the other project.
Please help me understand this mechanism and how should I add the dll of interest to my project to be able to access HttpContext in my library.
When should I use dotnet add package and when should I use NuGet packages management? Any good reading on this subject to bring me up to speed from .NET Framework 4.+ to .NET 7 in this area?
As .NET user for the last 10 years or so I feel so lost in the recent developments and find official docs I can find on the web of little use.
I tried adding the Microsoft.AspNetCore.App package through the "dotnet add package" command - Visual Studio complained, plus it pulled the entire bundle of assemblies but I care about only "Microsoft.AspNetCore.Http.Abstractions.dll".
I tried adding the "Microsoft.AspNetCore.Http.Abstractions" NuGet package but the version of assembly added was completely different to the one referenced in the WebAPI project.
What is weird is that when I click "Manage NuGet Packages" on this project I see absolutely no NuGet package already installed.
Those dependencies are determined by the project SDK which can be found in the root element of .csproj:
<Project Sdk="Microsoft.NET.Sdk.Web">
...
</Project>
So how should I add this dependency?
For latest versions of .NET you should reference corresponding SDK via FrameworkReference, for example to reference ASP.NET Core components you should add <FrameworkReference Include="Microsoft.AspNetCore.App"/> to library projects .csproj file as mentioned in the docs (and in the warning):
<Project Sdk="Microsoft.NET.Sdk">
<!--... rest of file-->
<ItemGroup>
<FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
<!--... rest of file-->
</Project>
I am referring to a sample ASP.NET core MVC solution. I want to know how do I have both .NetCoreApp 1.0 and .NETFramework 4.5.2 dependencies structure included to the solution as shown in the below image? Where do I add/organise the structure in that way?
It is best described here with the key difference being the TargetFramework to TargetFrameworks in your csproj file. You can edit it by right clicking on it or via the file system. See below for TargetFramework (ie targeting one framework):
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
See below for targeting multiple frameworks:
<PropertyGroup>
<TargetFrameworks>netstandard1.4;net40;net45</TargetFrameworks>
</PropertyGroup>
When targeting multiple frameworks your visual studio project structure will adjust to be like in the image you have.
You will also find the error process is a bit different when working in the IDE where it will take the perspective of one of the framework targets as a default in the IDE. When you build it may generate errors despite not showing you the error in the code editor (because the code editor might show framework but you may get netstandard compile errors etc). If you are concious of that, then its not an issue, but it did stump me at first.
Using VS 2017 RTM (and the latest preview from 3/16/2017) I am unable to get Xamarin Forms IntelliSense working in a shared project that targets NetStandard 1.4. It works in a PCL but once I target NetStandard (or create a new project library targeting NetStandard) I get no IntelliSense. Here is the relevant section of the CSPROJ file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard1.4</TargetFramework>
<PackageTargetFallback>$(PackageTargetFallback);portable-net45+net45+wp8+win81+wpa8;uap10.0;net46</PackageTargetFallback>
<AssemblyName>MyApp.AppX</AssemblyName>
<RootNamespace>MyApp.AppX</RootNamespace>
</PropertyGroup>
</Project>
It is a bug from Resharper and they have fixed in their latest beta. You can download the beta version of Resharper from here
I googled and checked existing post here but didn't find any relevant post so here is my question.
I am using VS2013 Primium edition. I have few class library projects(all using framework 4.0). When these class libraries become part of Web Solution, reference paths in the class library are shown and project compiles fine as shown below.
However, same class library project doesn't load reference paths when it becomes part of Windows Service Solution.
I doubled checked all my projects are using same framework version. Any idea whats going wrong?
finally I am able to resolve it.
After recreated my library project inside my Windows Service Solution as described here.
I opened same library project in my web solution. Somehow, my web solution adds nuGet restore tags in my library project file.
<RestorePackages>true</RestorePackages>
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
These tags were causing trouble. Once I removed those tags as described here. it fixed my issue.
I'm not able to copy the content static files in my .Net core web application project that I added when creating the nuget package using nuget package explorer. Same thing get copied correctly in .Net framework project template but not in .net core template. I'm using VS 2015 update 3.Am i Missing something here? Any help would be greatly appreciated.
Below is my snapshot of content file structure.
There is a nuget blog post about this, and it just isn't supported at this time.
Supported Project Types
This feature is only for packages that will be installed to projects that are managed using a project.json file. Currently only two projects types are managed by a project.json.
UWP apps
Portable class libraries
The contentFiles option is not available for other project types.
It's really a pity this basic functionality has been excluded from the .net Core projects. Especially because PCL is supported, which is a subset of a .net Core project.
There are quite some issues on GitHub about this, and it's very unclear whether or not this feature is coming back any time soon.
It seems it is still not supported. Only way to "hack" it is with MSBuild Targets and Build events.
According to this documentation:
build
MSBuild .targets and .props files Automatically inserted into
the project file or project.lock.json (NuGet 3.x+).
So to make it work with any file, e.g.: "config.xml" as Nuget Static Content:
Create your XY.nuspec file (as you would normally)
Include config.xml into the Nuget: <file src="config.xml" target="contentFiles\any\any\config.xml" />
Add a new .targets file XY.targets
Include new XY.targets file into your package to the "build" folder. <file src="XY.targets" target="build"/>
Content of the XY.targets file
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ContentFilesPath>$(MSBuildThisFileDirectory)..\contentFiles\any\any\</ContentFilesPath>
</PropertyGroup>
<Target Name="CopyConfigs" BeforeTargets="PreBuildEvent">
<Copy SourceFiles="$(ContentFilesPath)\config.xml" DestinationFiles="$(ProjectDir)config.xml" SkipUnchangedFiles="true" Condition="!Exists('$(ProjectDir)config.xml')"></Copy>
</Target>
</Project>
After packaging and installing the Nuget this MSBuild Target will be part of the Cached package and will run on each build (currently before build).
Issues with this solution:
Added files still linked until you build your solution. During the build paheses (BeforeTargets="") files are copied. Until this files still are just linked!!!
If you set up your content files to have Build actions and be copied to the Output directory of the project those settings will be lost!
Unfortunately this is the best solution for now.
Some public nuget packages (e.g. https://www.nuget.org/packages/NUnit3TestAdapter/3.10.0 or https://www.nuget.org/packages/Selenium.WebDriver.ChromeDriver/) can copy files. I've tried to investigate it (https://github.com/nunit/nunit3-vs-adapter and https://github.com/jsakamoto/nupkg-selenium-webdriver-chromedriver). But it seems, they have implemented very tricky workaround
After reading this post I came up with a work around. I created a .Net assembly project and completely emptied it out of all content. Then I moved the project into the same directory as the project for the .Net Core Web application. Instead of adding the NuGet package reference from the web application, I add it from the .Net assembly project. All of the files are correctly copied into the directory and are automatically added to the web project, since they share the same directory. This solution feels very dirty, but it is allowing me to manage static files with a NuGet package for a .Net Core Web project.