X.Y.Z.Sources nuget package

X.Y.Z.Sources.csproj

<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>

Found it.:

<PackageVersion>1.2.3.4</PackageVersion>

And the next question :)

Is there any way to define for the included content file that it should be copied to the output folder when the project that references the package is built?

@attilah where is the actual source code kept when the packages are referenced? Is there any way to copy them to the project like in the old days?

@georgiosd I'm sure there is a way, since you can derive the path of the source files from the referenced package's restored folder, but not sure why would you want that. It is like copying over dlls referenced from other packages.

@oleg-shilo to make source references work the project file nulls out the CopyFilesToOutputDirectory target which would interpret the copy to output folder related properties, so I think you cannot combine them with the standard method but you can define your own target that would do just that.

Txs. I is consistent with my observations.

@oleg-shilo Awesome ;-) sorry for the late answer somehow I missed the notification :-S

It happens to me a lot. GitHub sometimes does not send them diligently :)
No drama...

@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

@danielcrenna - you sir, are a beast :)

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.

@attilah I think it would be great if you added the property mentioned by @gitfool, SuppressDependenciesWhenPacking=true

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 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!

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>

<PackagePath>$(ContentTargetFolders)\cs\netstandard1.0\$(PackageId)\%(RecursiveDir)\</PackagePath>

This should not end with a \. Otherwise you'll get empty folders for the root content right under the project file.

@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