Multi-target nuget package does not include runtime files - nuget-package

I have a .NETStandard 2.0 class library which is distributed via Nuget. It includes compiled native code libraries, specific to our target platforms. The .csproj looks like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<PackageId>CoolProject</PackageId>
<Version>0.8.1</Version>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="AnotherCoolProject" Version="0.3.2" />
<PackageReference Include="YetAnotherCoolProject" Version="7.4.2" />
</ItemGroup>
<ItemGroup>
<None Pack="true" PackagePath="runtimes/win-x86/native/library32.dll" Update="library32.dll">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
<None Pack="true" PackagePath="runtimes/win-x64/native/library64.dll" Update="library64.dll">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
<None Pack="true" PackagePath="runtimes/linux-x64/native/liblibrary.so" Update="liblibrary.so">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
</ItemGroup>
</Project>
This works great with .NET Core apps on all supported platforms. Lately, though, we discovered issues using this library from .NET Framework apps - the runtime libraries aren't always copied over to referencing projects, leading to System.IO.FileNotFoundException exceptions. This appears to be related to this issue:
https://github.com/Microsoft/msbuild/issues/1582
As a workaround, we want to add a Framework 4.6.1 target to the package. If I just update the project file above, removing the TargetFramework property and adding
<TargetFrameworks>netstandard2.0;net461</TargetFrameworks>
the project builds without errors, and the nupkg is created with net461 and netstandard2.0 folders under lib/, but none of the runtime files are included anymore. I can verify this by unzipping the .nupkg, but it's pretty obvious as the package size goes from about 2mb to about 20kb. I've tried adding conditionals to the ItemGroup like
<ItemGroup Condition=" '$(TargetFramework)' == 'netstandard2.0' ">
But still nothing. What am I missing here?

Related

Publish .NET 7 Blazor to Linux doesn't have styles sheets

I am not sure where the component CSS files get put. I created the publish directory with VS2020 on Windows.
I had an ItemGroup to get it to copy the wwwroot folder.
<ItemGroup>
<None Include="wwwroot\**">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup>
None of my component CSS is getting published. It works fine on Windows.
Any suggestions?

Why is an Azure Function on .NET 6 looking for System.ComponentModel Version 6.0.0.0?

I am deploying an Azure Function called "Bridge" to Azure, targeting .NET 6. The project is referencing a class library called "DBLibrary" that I wrote, and that library is targeting .NET Standard 2.1. The Azure Function can be run locally on my PC without runtime errors.
When I publish the Azure Function to Azure, I see in Azure Portal a "Functions runtime error" which says:
Could not load file or assembly 'System.ComponentModel,
Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
The system cannot find the file specified.
I do not target System.ComponentModel directly, and I don't see a nuget package version 6.0.0 for "System.ComponentModel" available from any nuget feed. Why is the Azure function looking for this version 6.0.0 of System.ComponentModel? If that version does exist, why can't the Azure Function find it?
Here are the relevant parts of the csproj for the "Bridge" Azure Function:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Azure.Functions.Extensions" Version="1.1.0" />
<PackageReference Include="Microsoft.Extensions.Azure" Version="1.1.1" />
<PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="6.0.0" />
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.0.1" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\DBLibrary\DBLibrary.csproj" />
</ItemGroup>
</Project>
Here are the relevant sections of the csproj for the "DBLibrary" class library that is referenced by the Azure Function project:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.1</TargetFramework>
<ApplicationIcon />
<OutputType>Library</OutputType>
<StartupObject />
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Azure.Storage.Blobs" Version="12.10.0" />
<PackageReference Include="Dapper" Version="2.0.123" />
<PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="6.0.0" />
<PackageReference Include="System.Data.SqlClient" Version="4.8.3" />
<PackageReference Include="System.Text.Json" Version="6.0.2" />
</ItemGroup>
</Project>
I have tried setting _FunctionsSkipCleanOutput to true in the Azure Functions csproj because that was offered as a potential solution to nuget package resolution issues here:
https://github.com/Azure/azure-functions-host/issues/7061
That solution did not change the runtime error I saw in the Azure portal.
In my deployment pipeline, I was targeting functions runtime version ~2 for the Azure deployment when I should have been targeting version ~4 to support .NET 6. Changing to target version 4 of the Azure Functions runtime fixed the issue.
To find this setting on a deployed Function App, navigate to the Azure Portal (portal.azure.com) and search for the Function App resource's name there. Under the left navigation bar of the Function App, navigate to Settings > Configuration. After selecting the Configuration section, look for "Function runtime settings" at the top of the right pane to verify the Runtime version is "~4".
The function runtime version differences can be found here: https://learn.microsoft.com/en-us/azure/azure-functions/functions-versions?tabs=in-process%2Cv4&pivots=programming-language-csharp
This is the relevant part of the support table from the link above (as of February 2022):
Version
Support Level
Description
4.x
GA
Recommended runtime version for functions in all languages. Use this version to run C# functions on .NET 6.0.
If you have upgraded to .NET 6.0 you need to do the following to get past this error.
Update the cs proj to v4
Update the configuration in your function app in Azure to below
Update all the nuget packages for the solution
Clean the solution and then rebuild and it should work locally and should also work in Azure
The .net standard you are using 2.1 but ,Microsoft.Azure.Functions.Extensions can be support upto .NET Standard 2.0
You should add the below package to your function app and deploy to Azure again.
dotnet add package Microsoft.EntityFrameworkCore.SqlServer --version 5.0.0-rc.2.20475.6
Please refer this GitHub issue and this MICROSOFT BLOG by #Jeremy for more information.

Upgrade error on Azure functions

We are getting this error when attempting to upgrade the Azure functions project. This is the log file we are getting
Restoring packages for
C:\Users\User\Source\Repos\xxx_FileService\xxx.AzureFunctions\xxx.AzureFunctions\SE.AzureFunctions.csproj...
Detected package version outside of dependency constraint: Microsoft.NET.Sdk.Functions 1.0.7 requires Newtonsoft.Json (= 9.0.1) but version Newtonsoft.Json 10.0.3 was resolved.
Detected package downgrade: Microsoft.Azure.WebJobs from 2.1.0-beta4 to 2.1.0-beta1. Reference the package directly from the project to select a different version.
xxx.AzureFunctions -> Microsoft.NET.Sdk.Functions 1.0.7 -> Microsoft.Azure.WebJobs (= 2.1.0-beta4)
xxx.AzureFunctions -> Microsoft.Azure.WebJobs (>= 2.1.0-beta1)
Detected package downgrade: Microsoft.Azure.WebJobs.Extensions from 2.1.0-beta4 to 2.1.0-beta1. Reference the package directly from the project to select a different version.
xxx.AzureFunctions -> Microsoft.NET.Sdk.Functions 1.0.7 -> Microsoft.Azure.WebJobs.Extensions (= 2.1.0-beta4)
xxx.AzureFunctions -> Microsoft.Azure.WebJobs.Extensions (>= 2.1.0-beta1)
Detected package downgrade: Microsoft.Azure.WebJobs.Extensions.Http from 1.0.0-beta4 to 1.0.0-beta1. Reference the package directly from the project to select a different version.
xxx.AzureFunctions -> Microsoft.NET.Sdk.Functions 1.0.7 -> Microsoft.Azure.WebJobs.Extensions.Http (= 1.0.0-beta4)
xxx.AzureFunctions -> Microsoft.Azure.WebJobs.Extensions.Http (>= 1.0.0-beta1)
Package restore failed. Rolling back package changes for 'SE.AzureFunctions'.
Time Elapsed: 00:00:00.3832626
========== Finished =========
Package References in CS.PROJ
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup>
<TargetFramework>net461</TargetFramework>
<AssemblyName>SE.AzureFunctions</AssemblyName>
<RootNamespace>SE.AzureFunctions</RootNamespace> </PropertyGroup> <ItemGroup>
<PackageReference Include="Microsoft.Azure.WebJobs" Version="2.1.0-beta1" />
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions" Version="2.1.0-beta1" />
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.Http" Version="1.0.0-beta1" />
<PackageReference Include="Microsoft.Azure.WebJobs.ServiceBus" Version="2.1.0-beta1" />
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.0-alpha6" />
<PackageReference Include="Newtonsoft.Json" Version="10.0.2" />
<PackageReference Include="StyleCop.Analyzers" Version="1.1.0-beta004" /> </ItemGroup> <ItemGroup>
<Reference Include="Microsoft.CSharp" />
<Reference Include="System.Configuration" /> </ItemGroup> <ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None> </ItemGroup> </Project>
I will try to provide you with the background of why you are experiencing the challenge you are, as well as propose a solution for you.
Background of the issue:
the reason you are experiencing this error is rooted in two places:
Microsoft downgraded the following packages (as I am sure the error message you received may have clued you into):
a. Microsoft.Azure.WebJobs from 2.1.0-beta4 to 2.1.0-beta1
b. Microsoft.Azure.WebJobs.Extensions.Http from 1.0.0-beta4 to 1.0.0-beta1
In .NET Core 2.0.0 Preview 2 - downgrade warnings have become errors. What this means is that they are configured to treat the warning NU1605 as an error. This is not publicized in their release notes, but if you look into the Property Pages of any project that was templated off the .Net Core 2.0.0 Preview 2 (like I suspect your project is), you would notice that under the Build project properties sheet, the warning NU1605 is now being treated as an error (see the Treat warnings as an error section). Let's stick a pin in that for now as we would need to dive into the project's property pages in the proposed solution below.
Proposed Solution (Note this is a work around!):
Yup, you've guessed it, you need to configure your project to NOT treat the NU1605 warning as an error. To do that, follow these steps:
Open the property pages of your project,
Go to the Build properties sheet
Scroll down to the Treat Warnings as errors section, and clear the NU1605 value from the Specific Warnings radio box section. (See screen grab below)
Save and rebuild your project (Nuget might actually attempt to restore the packages automatically when you save your project property pages changes --- if it doesn't do that or if the restore "fails", just rebuild the project and you should be fine)
Conclusions
I am sure Microsoft has its reasons for enforcing the downgrade warning NU1605 as an error, so don't take this recommendation of disabling this warning as an error as a blanket endorsement of this tactic; instead treat this recommendation as a work around to a problem that we are all bound to experience when we chose to work with pre-release or beta code.
My hope is that come the final release candidate, most of these type of dependency issues would have been worked out and such work arounds will not be necessary, but in the mean time, and to keep your alpha/beta/experimental development moving forward, this work around should do.
Hope this helps you and happy coding (ohh yea, Happy new year!)

Visual Studio Code can't load projects - Microsoft.NET.Sdk.Web could not be found

I have a project folder in Visual Studio Code on Debian 9 with a Solution file that references two projects. When opening the folder, a banner appears saying "Some projects have trouble loading. Please review the output for more details". Viewing the output shows the following exception for the main WebAPI project:
[warn]: OmniSharp.MSBuild.MSBuildProjectSystem
Failed to load project file '/home/aidan/Projects/WebApiDemo/WebApiDemo/WebApiDemo.csproj'.
/home/aidan/Projects/WebApiDemo/WebApiDemo/WebApiDemo.csproj(1,1)
Microsoft.Build.Exceptions.InvalidProjectFileException: The SDK 'Microsoft.NET.Sdk.Web' specified could not be found.
The unit test project returns a similar The SDK 'Microsoft.NET.Sdk' specified could not be found.
All other answers to this type of question refer to a global.json file, which I don't have anywhere in my project - this was a new .NET Core 2 project, and not converted from an older version. Adding global.json does nothing. It was working at first, and I'm not sure what I changed to make it break. I do have the dotnet folder in my $PATH. The project file looks like this:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Folder Include="wwwroot\" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
</ItemGroup>
</Project>
Since I don't see any other explicit references to the SDK or its location in my project I'm stuck - any ideas what caused this to break?
Try to set MSBuildSDKsPath
export MSBuildSDKsPath=/opt/dotnet/sdk/2.2.105/Sdks

Building VS 2003 Solution Using Devenv.com on Build Server With Windows Server 2008 R2

I am trying to build .NET Framework 1.1 solution (VS 2003) on a TFS build server 2008 which is on windows server 2008 R2 machine. I am following the instructions from this website
http://blogs.msdn.com/b/nagarajp/archive/2005/10/26/485368.aspx
and going for the second solution suggested. The build server goes through the first 4 steps fine (Initializing build, Getting Sources, Labelling Sources and Compiling Sources for any cpu/release) but after then it just shows that Build in progress and does not do anything. I left the job running overnight and it still shows Buiid In progress. I checked the event log and it displays the following message:
The application (Visual Studio .NET 2003, from vendor Microsoft) has the following problem: Visual Studio .NET 2003 has a known compatibility issue with this version of Windows.
When i log in to the build server and then try opening Visual Studio 2003, it shows me a pop up window with the same message and then i have to click Run Program to go further. But since i am building the solution using command line, i am wondering how can i do that? I have also tried to run this program in compatibility mode (windows xp service pack 3) and checked the options "Disabe visual themes" and "Disable desktop composition" but no luck. Can anyone please help?
This is the modified version of the configuration file for 1.1 Framework project to get build with Build Server 2008 on Windows Server 2008 R2:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
<ProjectExtensions>
<ProjectFileVersion>2</ProjectFileVersion>
<Description></Description>
<BuildMachine>UNKNOWN</BuildMachine>
</ProjectExtensions>
<PropertyGroup>
<TeamProject>1.1 Framework</TeamProject>
<BuildDirectoryPath>UNKNOWN</BuildDirectoryPath>
<DropLocation>\\UNKNOWN\drops</DropLocation>
<RunTest>false</RunTest>
<RunCodeAnalysis>Never</RunCodeAnalysis>
<WorkItemType>Bug</WorkItemType>
<WorkItemFieldValues>System.Reason=Build Failure;System.Description=Start the build using Team Build</WorkItemFieldValues>
<WorkItemTitle>Build failure in build:</WorkItemTitle>
<DescriptionText>This work item was created by Team Build on a build failure. </DescriptionText>
<BuildlogText>The build log file is at:</BuildlogText>
<ErrorWarningLogText>The errors/warnings log file is at:</ErrorWarningLogText>
<UpdateAssociatedWorkItems>true</UpdateAssociatedWorkItems>
<AdditionalVCOverrides></AdditionalVCOverrides>
<CustomPropertiesForClean></CustomPropertiesForClean>
<CustomPropertiesForBuild></CustomPropertiesForBuild>
</PropertyGroup>
<ItemGroup>
</ItemGroup>
<ItemGroup>
<ConfigurationToBuild Include="Release|Any CPU">
<FlavorToBuild>Release</FlavorToBuild>
<PlatformToBuild>Any CPU</PlatformToBuild>
</ConfigurationToBuild>
</ItemGroup>
<ItemGroup>
</ItemGroup>
<PropertyGroup>
<VS2003_Devenv>C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Common7\IDE\devenv.com</VS2003_Devenv>
<VS2003_Configuration>Release</VS2003_Configuration>
</PropertyGroup>
<ItemGroup>
<VS2003_OutputFiles Include="$(SolutionRoot)\DSC.STARS\Main\DSC.STARS.Web\**\*.*" />
</ItemGroup>
<Target Name="AfterCompile">
<Exec Command=""$(VS2003_Devenv)" "$(SolutionRoot)\DSC.STARS\Main\DSC.STARS.SOLUTION.sln" /build release" />
<MakeDir Directories="$(BinariesRoot)\$(VS2003_Configuration)" Condition="!Exists('$(BinariesRoot)\$(VS2003_Configuration)')" />
<Copy SourceFiles="#(VS2003_OutputFiles)" DestinationFiles="#(VS2003_OutputFiles- >'$(BinariesRoot)\$(VS2003_Configuration)\%(RecursiveDir)%(Filename)%(Extension)')"/>
</Target>
</Project>

Resources