Sdk: PP file output is not generated during the build

[emgarten]

PP file output is not being generated during the build.

Steps

1. dotnet new
2. dotnet add package contentfilesexample -v 1.0.2
3. dotnet restore
4. Add to Program.cs Console.WriteLine(ExampleReader.GetDataText());
5. dotnet build

Expected

ExampleReader will be in the current namespace from the pp file.

Actual

ExampleReader does not exist

Originally reported here https://github.com/NuGet/Home/issues/4803 //cc @damianh

From @natidea

I took a look at the pp file transformation issue and found a couple of things:

• For the ContentFilesExample package, I don't see pp files listed as dependencies in the assets file. They occur in the "libraries" but we are only processing content from the active TFM here: Microsoft.PackageDependencyResolution.targets#L213
• For the LiteGuard package, I do see the pp files in the dependencies, but they were not being processed because CopyLocalLockFileAssemblies=false here: Microsoft.PackageDependencyResolution.targets#L414
  I was able to fix this by setting the property in my project file:

    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>

Now I can use the Guard.

So somewhere along the way, some concepts may have been crossed. We default CopyLocalLockFileAssemblies to true in that target file, but it gets set to false in Microsoft.NET.Sdk.BeforeCommon.targets#L57. Perhaps the real issue is that the produce content assets task is tied to ResolveLockFileCopyLocalProjectDeps and should instead be triggered in some other way.

[jonsequitur]

I'm seeing the same behavior with plain old un-preprocessed C# files.

Work in progress trying to get this to work is here: https://github.com/jonsequitur/PocketContainer/tree/netcore-support

[emgarten]

@jonsequitur there shouldn't be any extra steps needed for .cs files. Check your props file under obj\projectname.csproj.nuget.g.props to see how your files are getting referenced from the package.

[jonsequitur]

I see. I was hitting a bug where Visual Studio needs to be reopened before it will build the referenced file.

[mynkow]

Please move this to milestone: 2.1.0

[jainaashish]

This is important for customers to move from packages.config to PackageReference, so can we get some traction on it? And tries to make it for 2.1.0?

[adamralph]

I'm not sure this problem exists any longer. I just tried to reproduce it like so:

1. Clone or download https://github.com/adamralph/blunt
2. dotnet add package LiteGuard.Source
3. dotnet restore
4. Open Foo.cs, and add Guard.AgainstNullArgument("baz", baz); to Foo.Bar()
5. dotnet build

Everything works perfectly!

λ dotnet --info

.NET Command Line Tools (2.0.0)

Product Information:
Version: 2.0.0
Commit SHA-1 hash: cdcd1928c9

Runtime Environment:
OS Name: Windows
OS Version: 10.0.15063
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.0.0\

Microsoft .NET Core Shared Framework Host

Version : 2.0.0
Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

[damianh]

Am going to make another attempt https://github.com/damianh/LibLog/pull/149

[leastprivilege]

Was this ever resolved? It seems pp files are simply ignored..

[serialseb]

@adamralph it doesn't seem to me you're using pp files, that may be the reason

[leastprivilege]

I should mention I got it working in the end.

[adamralph]

@serialseb the LiteGuard.Source package does contain pp files. See https://github.com/adamralph/liteguard/blob/master/src/LiteGuard/contentFiles/cs/netstandard2.0/Guard.cs.pp

[serialseb]

That's good to know. SHould this issue be marked as fixed then?

[livarcocc]

It seems we can now close this issue. Doing so now. If that's not the case, just comment and we can re-activate, or file a new issue.

[ahmoh]

I tried to make it work with LiteGuard.Source package but the .pp file doesn't get generated.

[adamralph]

@ahmoh I'm not sure what you mean. When you install the LiteGuard.Source package in a project, the .pp files are lifted from the package and transformed into .cs files for compilation. There is no _generation_ of .pp files in that workflow.

[ahmoh]

@adamralph Sorry, wrong choice of word. What I meant is transform .pp into .cs. When I install the package LiteGuard.Source shouldn't the file Guard.cs.pp be transformed into Gauard.cs and copied to the root folder of the project?

I ran the test project in .net core console application with dotnet version = 2.1.200.

[adamralph]

@ahmoh it doesn't work like that anymore. The pp file still gets transformed, but the resulting cs file doesn't appear anywhere. You can still use the Guard class as if it was part of your project.

Here's an example: ConsoleApp9.zip

[ahmoh]

@adamralph thanks for the example, but I was able to get that outcome also before. I'm disappointed that this feature doesn't work in .net core as it does in .net framework project.

[damianh]

Finally released LibLog v5.0.0 with netstandard2.0 and SDK project support (It won't work in non-sdk projects, previous version should be used for that).

[adamralph]

@ahmoh what problems does the new mechanism cause you?

[ahmoh]

@adamralph I want the user to be able to find the source file easily so he/her can edit it. Now it's hidden in my opinion. Aslo this documentation is misleading, you think that the files under contentFiles/any/any/Source.cs.pp will be installed in the root folder of the project.

[adamralph]

@ahmoh I'd argue that the ability to edit the source code of the package was a _problem_ with the old system. What happens when a new version of the package is released? Editing the code is effectively forking the package. Source code packages are the wrong mechanism to distribute code which is intended to be edited. You should be using templates for that.

[ahmoh]

@adamralph interesting idea about templates. As long as I can accomplish my implementation. I'll give it a go.

[augustoproiete]

Source code packages are the wrong mechanism to distribute code which is intended to be edited. You should be using templates for that.

@adamralph Do you mean Visual Studio Project Templates or something else (that can be distributed via NuGet)?

The nice thing about NuGet is the composability it gives us, and how easy it is to install from the PowerShell console. Let's say I want to create

• An Excel Add-In (say, with Excel-DNA)
• That uses DevExpress controls (say, via DevExpress-NuGet)
• That gets packaged into a single file (say, via Fody.Costura)

With the old NuGet Package reference model, I can:

• Create an empty Class Library project
• Add the ExcelDna.AddIn NuGet package to it
  
  
  
  • Getting a nice .dna config template file that I can modify / customize for my project
  
  
• Add DevExpress-NuGet package(s) to it
• Add the Costura.Fody NuGet package to it
  
  
  
  • Getting a nice .xml config template file that I can modify / customize for my project
  
  

---

How would the above scenario work with the templates you mentioned?

If they were project templates, I'd have to choose 1 - either start with an Excel-DNA project template, or a DevExpress project template or a Costura.Fody project template... That doesn't work.

If they were project item templates, I'd have to install 6 different things (3 NuGet packages and 3 VSIX) instead of 3 - or am I missing something?

[dasMulli]

There's also the new dotnet new templates which also supports item templates.
Those can be installed via dotnet new --install NuGet.Pkg.Name.Of.TemplatesPkg. This could allow for dotnet new dnaconfig.

Dropping files into the project will depend on the project type..

Quite a few projects used app.config transforms that were applied to the project's app.config file. But since not all runtimes (.NET Core) use this file or relevant sections of this file, that may be pretty useless.

[augustoproiete]

@dasMulli Good point on dotnet new. However, why make that an extra step for the developer - who would have to read the documentation to understand that after installing the nuget packages, he/she needs to run dotnet new dnaconfig then dotnet new fodyconfig etc...

The current NuGet Package Reference approach is so much better in that aspect, that the user is up and running after a single install-package bla, given that it brings everything he/she needs to get started...

[dasMulli]

install-package is a vs-only concept though.
Users are also taught that they can just add <PackageReference> items into the csproj on platforms where there is no NuGet tooling. dotnet add package does the same as well and afaik doesn't even run init.ps1 (simply because there isn't a PowerShell Core runtime bundled with dotnet).

The next point is that updates never really worked if you needed to roll out a change to the default file..

[dfoulk]

@adamralph @dasMulli - Are you guys saying that it's no longer possible to add/update files in a user's project? If so, then I think some edge cases have been left unconsidered...

For example, we're trying to work out how to add a Xamarin.Android/Resources/values/colors.xml file and update a user's Xamarin.Android/Resources/values/styles.xml with the colors from colors.xml (via our Xamarin.Forms theme plugin). The changes simply apply our company color scheme to the Android version of the app.

Once installed, these values won't change- but even if they did, the updates would be reflected as desired. Am I missing something?

If this functionality is not possible, it would be great to find out for sure so that we can move to "plan b". I really hope this is doable as it seems like it was possible before!

[adamralph]

Perhaps there are scenarios which are not covered. WRT to source code I believe the new mechanism is better than the old. For templating, there is also SideWaffle which has item templates as well as project templates. Templating is a better mechanism than packages for content that is intended for editing. In that scenario, you effectively want a "snapshot" of external content at some point in time which you then evolve to your needs, rather than taking a permanent _dependency_ on a package, the contents of which will follow it's own path of change.

[dfoulk]

@adamralph - Thank you for the link. I will check it out!

The example I provided was just a portion of the overall package we were building. The other part(s) of the package contained a Xamarin.Forms theme (resource dictionary) as well as some other Xamarin.Forms controls. The overall package was designed to completely theme each of our new and existing applications to the corporate "theme"/"layout" (which in Xamarin.Forms requires supplemental files to added/updated to achieve).

I suppose it is just frustrating that we can no longer copy files to disk while managing versions via NuGet Package Manager- especially considering that said functionality was present in previous versions.

Can we still copy files to disc using non-.NET Standard libraries? If so, would you mind sharing how we can still do this? I heard mention of .NET Standard packages using Init.ps1 to copy files into the user's project (somehow)? Any information would be greatly appreciated!

[adamralph]

I'm afraid I don't know anything about these special use cases. I don't have a need for them.

[dfoulk]

Lol worth a shot- thanks man!