In our work we have one team that develops libraries and other teams that develop projects using those libraries.
The libraries team has much more experience than the projects one.
We created this environment here:
All the libraries are in nuget packages, in a nuget server, in azure devops. We have source link in Azure devops.
But when we deploy the libraries, we have to choose between debug or release, and we have the pros and cons of each.
My ideal nuget package would have both debug and release, and would select the same as the project running it.
this way I would have better debugging for the projects team, and maximum performance on the releases.
I talked with https://twitter.com/rrelyea and he gave some ideas, but they seem to complicated for the other teams to implement, or complex do manage.
Like 2 nuget servers, one for debug, and one for release, and configure those different ones on the machines and on the build server.
Or 2 nuget packages, with .debug and .release on the name of the package, and configure the project to load a diffent one on each mode.
The real problem is that I need a guarantee that all the packages have the same id and version on both servers.
Isn't there a more automatic way to pack the packages?
Simple if it's debug use the debug, if it's the release use the release.
By the way, how much performance difference is between debug and release in this case?
Isn't there a more automatic way to pack the packages?
Actually, nuget package does not have a mechanism to let a project to reference the debug output files or release output files based on the configuration of the main project.
And when you pack a project, it does not have a function to include the Debug or Release output files at the same time and then let the main project-------when using Debug, reference the Debug content of the nuget, when using Release, reference the Release content of the nuget.
So far, nuget is not yet so flexible, and it can't do the functions you mentioned above.
As a suggestion, you should create two nuget packages(Debug or Release) of the project and then manually install the corresponding package as required.
You can create a net standard library project, and add these in xxx.csproj file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<RootNamespace>PackageName</RootNamespace>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)'=='Debug'">
<PackageId>PackageName_Debug</PackageId> //name the nuget package which contains Debug key name
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)'=='Release'">
<PackageId>PackageName_Release</PackageId> //name the nuget package which contains Debug key name
</PropertyGroup>
<PropertyGroup>
<Version>1.0.0</Version>
<Authors>your_name</Authors>
<Company>your_company</Company>
</PropertyGroup>
<ItemGroup Condition="'$(Configuration)'=='Debug'">
<None Include="$(ProjectDir)$(OutputPath)$(AssemblyName).pdb" Pack="true" PackagePath="lib\$(TargetFramework)"></None>
<Compile Update="Class1.cs" Pack="true" PackagePath="Resource">
</Compile>
...// add any source files
</ItemGroup>
</Project>
And you can switch the Configuration to Debug or Release to build your project to generate the nupkg file under output folder.
Note:
1) To generate a debug nuget package, you should contains the pdb file and source files into the nuget package and then you can debug it in the main project. There is a similar issue which contains the detailed steps about it.
2) You can define the package_id directly in the new sdk format project. And you should add Debug or Release to distinguish between them.
More info about packing new sdk format project, you can refer to this document.
In addition, if you still want the initial feature(contain Debug or Release in the same package), you could suggest a feature on our User Voice Forum and I hope the Team will consider you idea carefully and give a satisfactory reply.