Closed jongalloway closed 7 years ago
@dotnet/msbuild thoughts?
+1
I really like this one. The less XML I have to write the better.
perhaps Microsoft.common.props could be considered a standard implementation-defined prelude..
Would love to see these removed!
Had exactly the same thoughts after reading this https://blogs.msdn.microsoft.com/dotnet/2016/10/19/net-core-tooling-in-visual-studio-15/
How about a csproj without <PropertyGroup>
, <ItemGroup>
, the 2 default imports and an implicit <Compile Include="**\*.cs" />
<Project>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.0</TargetFramework>
<PackageReference Include="Microsoft.NETCore.App" Version="1.0.0" />
<PackageReference Include="Microsoft.NET.SDK" Version="1.0.0" />
</Project>
Do keep in mind how alternate project systems (VB/F#/etc) might want to define a common set of import targets that aren't the C# ones.
@baronfel Sure, but VB and F# don't use .csproj
files, so it should be possible to figure this out based on the extension of the project file.
@filipw
Let's keep this issue focused on imports. Feel free to file a separate issues for PropertGroup/ItemGroup removal.
@terrajobst @filipw
Created the issue: #632
@MaximRouiller Thanks!
I don't see a way to make this work without breaking many existing MSBuild users.
While trying to find a way to do something like this, we saw several problems:
.csproj
file actually imports these files.Microsoft.Common.props
import.Microsoft.CSharp.targets
--which requires defining the override after the import..props
/.targets
pair that applies customizations even to things that are at heart standard C# projects.Since this would be a nice boilerplate-reduction, but in the end saves only a couple of lines per project, we opted to spend our development time elsewhere (allowing item metadata in properties saves 2 lines/NuGet reference, better supporting wildcards in the IDE saves a ton of lines, and so on).
@rainersigwald
This was moved to https://github.com/Microsoft/msbuild/issues/1236
At least, we now have a tracking of why it wouldn't work.
If anyone asks, we can say:
See Issue #???
@MaximRouiller, I believe @rainersigwald's response is about the original issue here of not having to import the targets\props.
@srivatsn Ah! My misunderstanding. Time to hit the coffee shop I guess. ☕️
Perhaps this could be implemented in a backwards-compatible way by adding an attribute to the Project
element that allows one to opt-in to the desired behavior.
Perhaps this could be implemented in a backwards-compatible way by adding an attribute to the Project element that allows one to opt-in to the desired behavior.
Another way to do this would be to only import the default props and targets files if there is no xmlns
attribute on the Project
element. That attribute will no longer be necessary so we could use it to light up new, but not backwards compatible, functionality.
If we do this based on the xmlns
, I'd suggest allowing a UseDefaultImports="false"
property on the Project
element to disable the default imports in case you want to do something before the props or after the targets or you just don't want to use the default imports at all.
This is possible for new .NET Core projects with https://github.com/Microsoft/msbuild/pull/1403, released with the updated VS2017 RC.
Every example csproj file includes two imports - one for
Microsoft.common.props
at the beginning and one forMicrosoft.CSharp.targets
at the end:Couldn't these two imports be implied, with an option to override them if needed?
I understand this may have been discussed internally, but would like to have it publicly documented and tracked since it will likely be a common question.