Sdk: New tooling leaves a mess under obj, causing duplicate attribute problems

[mgravell]

The current dotnet build tooling seems to leave files such as obj/{configuration}/{platform}/dotnet-compile.assemblyinfo.cs. This can break some existing builds, for example in dapper we use out-of-project file references:

  "compile": [
    "../Dapper/**/*.cs"
  ],

This worked fine previously, but now creates things like:

error CS0579: Duplicate 'System.Reflection.AssemblyInformationalVersionAttribute' attribute

(because of course it finds the file for each platform and/or configuration)

We can fix this by adding:

   "compileExclude": [
    "../Dapper/obj/"
  ],

But; this seems pretty horrible. I'm not saying the setup is perfect here, but it seems like maybe the tooling should default to ignoring files that _it almost certainly created_ (for a different purpose, and unless it knows that it really wants it for what it is currently doing). Or alternatively: don't leave such things behind ;p

[mgravell]

update: I tried fixing this by moving both projects into the same folder using {ProjectName}.project.json, but that also ended badly, with them squabbling

[blackdwarf]

/cc @piotrpMSFT

[TheRealPiotrP]

@mgravell you have two options here:

1. As you said, you can explicitly exclude
2. You can use dotnet build --build-base-path <OUTPUT_DIR> to redirect build output to a directory outside your source directory.

obj is intentionally not cleaned up. Since this directory contains artifacts that were generated during and used by compilation, we need to preserve them to take magic out of the system.

[davidfowl]

Hmmm, I'm not sure about that one. That seems like a pretty bad problem that should be fixed.

[NickCraver]

This is still a problem in RC2.

[NickCraver]

This is still a problem in RTM (Preview 2 tooling).