|<Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" />|
|<PackageReference Remove="@(PackageReference)" />|
|<Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" />|
|<Target Name="Compile" />|
|<Target Name="CopyFilesToOutputDirectory" />|
@attilah This is great work, thanks for sharing. Do you have a license file you can add?
I modified it to support
When generating the NuGet package version with SourceLink I had to remove the following:
<ItemGroup> <PackageReference Remove="@(PackageReference)" /> </ItemGroup>
... but now I can suppress the framework dependencies using:
<PropertyGroup> <SuppressDependenciesWhenPacking>true</SuppressDependenciesWhenPacking> </PropertyGroup>
@oleg-shilo to make source references work the project file nulls out the
@attilah my question wasn't clear I guess, it's two-fold :)
a) I am puzzled as to where the source files are stored if not added to the project itself LOL
b) I am wondering if you know how to modify this setup such that the files are copied to the project like nuget used in the early versions. The reason for this, is to be able to maintain source code bases without necessarily maintaining a custom nuget server. Each project will own the source code of the version of the package that was imported, kinda like git submodules.
@georgiosd I struggled with that as well, and this is what I came up with: https://github.com/hq-io/Community/tree/master/Squire
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.
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?
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
I created that sample project to demonstrate the problem.
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
(the output is from the
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>
I could find a fix for the problem.
to your WPF project.