Project System unconditionally declares the AssemblyName and other properties.

From @tannergooding on January 28, 2017 16:53

Description

In MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.props there are several properties which are unconditionally defined:

  <!-- User-facing configuration-agnostic defaults -->
  <PropertyGroup>
    <OutputType>Library</OutputType>
    <FileAlignment>512</FileAlignment>
    <ErrorReport>prompt</ErrorReport>
    <AssemblyName>$(MSBuildProjectName)</AssemblyName>
    <RootNamespace>$(MSBuildProjectName)</RootNamespace>
    <Deterministic>true</Deterministic>
  </PropertyGroup>

  <!-- User-facing configuration-specific defaults -->

  <PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
    <DebugSymbols>true</DebugSymbols>
    <Optimize>false</Optimize>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
    <Optimize>true</Optimize>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Platform)' == 'x64' ">
    <PlatformTarget>x64</PlatformTarget>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Platform)' == 'x86' ">
    <PlatformTarget>x86</PlatformTarget>
  </PropertyGroup>

  <!-- Default settings for all projects built with this Sdk package -->
  <PropertyGroup>
    <DebugType>portable</DebugType>

These will override any values that the user may have defined before the parent Sdk.props file was imported.

Expected Behavior

For the properties which can be overridden by the user (such as AssemblyName) they should be conditioned to only set the default if it isn’t already set.

For the properties which are not allowed to be overridden (possibly DebugType), at the very least, a warning should be given if it was already set to a different value.

Copied from original issue: dotnet/roslyn-project-system#1360

[jaredpar]

MSBuildSDKsPath needs to be set as an environment variable, not an MSBuild property.

It also doesn’t seem to be absolutely necessary. After chatting with @nguerrera I just switched our <Import> to not have an Sdk attribute and use full paths instead. Seems to work just fine.

We moved away from that because there was too much VS integration in the SDK for a project to work well before the SDK was restored.

This seems fairly solvable. I agree it presents a couple challenges but was pretty easy to adapt to in our repo. Feels like a big price to pay to remove the ability to override the SDK without admin privs because some developers wouldn’t want to work around this bootstrapping problem.

[tannergooding]

@jeffkl, in addition to the contents of Microsoft.NET.Sdk.props it looks there are some defaults in Microsoft.NET.Sdk.CSharp.props and Microsoft.NET.Sdk.VisualBasic.props that should be conditioned.