-
-
Save attilah/fd3e71f03fd258c496179e0200c57b0b to your computer and use it in GitHub Desktop.
<Project> | |
<Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" /> | |
<PropertyGroup> | |
<TargetFramework>netstandard1.0</TargetFramework> | |
<IsPackable>true</IsPackable> | |
<IncludeBuildOutput>false</IncludeBuildOutput> | |
<ContentTargetFolders>contentFiles</ContentTargetFolders> | |
<DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences> | |
<GenerateAssemblyInfo>false</GenerateAssemblyInfo> | |
<GenerateTargetFrameworkAttribute>false</GenerateTargetFrameworkAttribute> | |
<NoWarn>CS8021</NoWarn> | |
<NoBuild>true</NoBuild> | |
<GeneratePackageOnBuild>true</GeneratePackageOnBuild> | |
<SuppressDependenciesWhenPacking>true</SuppressDependenciesWhenPacking> | |
</PropertyGroup> | |
<ItemGroup> | |
<Compile Update="@(Compile)"> | |
<Pack>true</Pack> | |
<PackagePath>$(ContentTargetFolders)\cs\netstandard1.0\$(PackageId)\%(RecursiveDir)\</PackagePath> | |
</Compile> | |
<EmbeddedResource Update="@(EmbeddedResource)"> | |
<Pack>true</Pack> | |
<PackagePath>$(ContentTargetFolders)\any\any\$(PackageId)\%(RecursiveDir)\</PackagePath> | |
</EmbeddedResource> | |
</ItemGroup> | |
<ItemGroup> | |
<PackageReference Remove="@(PackageReference)" /> | |
</ItemGroup> | |
<Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" /> | |
<Target Name="Compile" /> | |
<Target Name="CopyFilesToOutputDirectory" /> | |
</Project> |
Hi, i've been using this for a little but what i found out is that sometimes source only packages aren't the best, but sometimes i really need em, but i always want to maintain just one code base.
So starting from here i've tried to add configurations, just to fail miserably, i'll share a gist of what i've tried so far, but i have to separate it from the actual project i've tried it on.
Did someone already tried that ? got any advice ?
I've managed to make it work.
The tricky part where the Target tags, that where overriding the imported targets even with the condition specified. putting them in a separate file that get imported only when needed yielded the desired result.
My version of this Gist is here.
When .NET 5.0 SourceGenerators are able to actually reference other .NET Standard libraries through the Roslyn Analyzers path (see: dotnet/roslyn#43903), I think this will be a preferred way to ship sources, since you are able to control their generation at the user's build time, which makes most scenarios we wish we had with source packages (like getting updates or tweaking values post-install) first-class experiences, again.
Just one question: Do project references to this projects still work?
We have the habit of using project references of "nuget packaged" projects within the same solution, so when building the solution, we get the latest changes without the roundtrip of CI system and NuGet Package.
@kzu updated the gist with the property
It seems that project references do not work, and another problem seems to be that, while the ResX files are included within the NuGet Package, they're ignored (not processed) in the referencing project.
It seems to be hard to find documentation about this. :-(
I put a small code example on github: https://github.com/markusschaber/SourceOnlyNugetTest
The ConsoleApp1 fails with MissingManifestResource Exception.
Hello,
Thank you for that great example and medium article.
I tried to use it but I experienced some issues when using it in an WPF environment.
As soon as an UserControl
is added to the Project, the compailer cant find the nuget imported c# files.
I created that sample project to demonstrate the problem.
Can anyone help here? ;) Thank you!
Added support in NuGetizer for the SuppressDependenciesWhenPacking
property: devlooped/nugetizer#68
I learned about it thanks to this gist, so, thanks!
@kzu can NuGetizer be used to define NuGet source packages more concisely?
Oh, absolutely.
The above sample would look like the following:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard1.0</TargetFramework>
<PackageId>X.Y.Z</PackageId>
<PackBuildOutput>false</PackBuildOutput>
<PackCompile>true</PackCompile>
<PackEmbeddedResource>true</PackEmbeddedResource>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="NuGetizer" Version="0.6.0" />
</ItemGroup>
</Project>
And given a couple .cs and a .resx, you'd get a package with the following content after running dotnet restore
followed by dotnet pack
:
Package: X.Y.Z.1.0.0.nupkg
C:\Delete\sourceonly\bin\X.Y.Z.nuspec
Authors : X.Y.Z.Sources
Description: Package Description
Version : 1.0.0
Contents:
/contentFiles/
any/
netstandard1.0/
Properties/
Resources.resx (buildAction=EmbeddedResource)
cs/
netstandard1.0/
Program.cs (buildAction=Compile)
Shared/
Helper.cs (buildAction=Compile)
(the output is from the dotnet-nugetize
global tool, which can be run simply with nugetize
on the project directory).
The actual console output looks way nicer though ;)
It makes it very easy to quickly iterate on the packaging structure without ever having to build or even pack/zip files.
If you wanted the .resx to also be provided only for the cs code language you just update those appropriately:
<ItemGroup>
<EmbeddedResource Update="@(EmbeddedResource)" CodeLanguage="cs" />
</ItemGroup>
pwsh> nugetize
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:01.61
Package: X.Y.Z.1.0.0.nupkg
C:\Delete\sourceonly\bin\X.Y.Z.nuspec
Authors : X.Y.Z.Sources
Description: Package Description
Version : 1.0.0
Contents:
/contentFiles/
cs/
netstandard1.0/
Program.cs (buildAction=Compile)
Properties/
Resources.resx (buildAction=EmbeddedResource)
Shared/
Helper.cs (buildAction=Compile)
Hello,
Thank you for that great example and medium article.
I tried to use it but I experienced some issues when using it in an WPF environment.
As soon as anUserControl
is added to the Project, the compailer cant find the nuget imported c# files.I created that sample project to demonstrate the problem.
Can anyone help here? ;) Thank you!
I could find a fix for the problem.
You have to add
<IncludePackageReferencesDuringMarkupCompilation>true</IncludePackageReferencesDuringMarkupCompilation>
to your WPF project.
@kzu I switched to NuGetizer in gitfool/Cake.Dungeon@9a0080b and all the csproj
black magic disappeared. ❤️
Awesome stuff @gitfool :D
@kzu I'm using nugetizer but I'm using a sqlproj non-standard sdk that requires the files to be buildAction=content. The files are included in the nupkg and in my test project but they default to buildAction=compile. Is there a way I can force them to be content either from the nupkg or from the csproj ?
Absolutely! See https://github.com/devlooped/nugetizer/blob/main/src/NuGetizer.Tasks/NuGetizer.props#L89.
You can just add the following to change that default value for all Content items:
<ItemDefinitionGroup>
<Content>
<BuildAction>None</BuildAction/>
</Content>
</ItemDefinitionGroup>
@inkahootz is that nugetizer or SDK pack?
@inkahootz is that nugetizer or SDK pack?
SDK pack. The code from the gist is producing that.
Gist explanation: https://medium.com/@attilah/source-code-only-nuget-packages-8f34a8fb4738
@danielcrenna - you sir, are a beast :)