Sdk: error NETSDK1085 during Roslyn builds with 3.0.100 preview 4 sdk

[JoeRobich]

When building Roslyn with 3.0.100-preview4-010381 installed, I get the following error on every solution build.

8>------ Build started: Project: VS.Tools.Roslyn.Package, Configuration: Debug Any CPU ------
2>C:\Program Files\dotnet\sdk\3.0.100-preview4-010381\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(112,5): error NETSDK1085: The 'NoBuild' property was set to true but the 'Build' target was invoked.
2>Done building project "IlAsmDeploy.csproj" -- FAILED.

[livarcocc]

I believe this is by design: https://github.com/dotnet/sdk/commit/af4fc22af555a2cc647dc533436e764759ad827f

Seems like Roslyn might be doing the wrong thing here and was just getting lucky so far.

cc @peterhuene

[peterhuene]

@JoeRobich can you email me a binlog? I'm not sure what would be setting NoBuild to true.

[JoeRobich]

@peterhuene I'll send one shortly. thanks

[peterhuene]

It looks like it's coming from here:

https://github.com/dotnet/roslyn/blob/d7e493956ffcbf0e932097f6f3e1fa3fa1699087/src/Tools/ILAsm/IlAsmDeploy.csproj#L16

NoBuild is used for more than just packaging, it's also used for .NET Core SDK publishing targets. The SDK is now respecting the intent of NoBuild by failing if the Build target gets triggered when NoBuild is true. This helps to ensure what you're packing or publishing is exactly what was built previously.

I see that NuGet actually has an example of setting NoBuild in a project file in the documentation.

If this is commonly done in the project file like this, then I can think of a potential solution that would limit the error to when --no-build is passed to dotnet pack and dotnet publish only. If it was set in the project file only then we'll bypass the check.

[peterhuene]

From the NuGet docs, though, the example project file with NoBuild set is really just for use with dotnet pack as a simple way to pack based on a nuspec. The intention is that you wouldn't build a project with NoBuild set (in fact, it explicitly disables looking for the project output to pack since the project is only a (hacky) mechanism to enable packing from a nuspec alone).

So even if users are following this example, I don't think they are also trying to dotnet build these projects.

[tmat]

If you look at the project, it runs Publish on itself after Build:
https://github.com/dotnet/roslyn/blob/d7e493956ffcbf0e932097f6f3e1fa3fa1699087/src/Tools/ILAsm/IlAsmDeploy.csproj#L48

We don't want to build again in that case.

[peterhuene]

Could we limit the setting of NoBuild to where we invoke the Publish target? That should workaround this issue.

[tmat]

Yes, that would work.

[nguerrera]

It's not going to build again unless you set global properties in the MSBuild invocation because MSBuild targets run at most once per (project + global properties). So I guess moving NoBuild to where the Publish is invoked is OK, but I don't think it will do anything useful for you if you always run Publish after Build in the same evaluation.

[tmat]

I see, so we can just remove NoBuild.

[tmat]

@JoeRobich Could you send a PR?

[JoeRobich]

@peterhuene We've removed NoBuild from the offending project and things build as expected again. Thanks for your help.