Project file cleanup of migrated projects
See original GitHub issueSteps to reproduce
dotnet migrate a simple app
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
},
"MyLib": "1.0.0-*"
},
"frameworks": {
"netcoreapp1.0": {
"imports": "dnxcore50"
}
}
}
Expected behavior
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" />
<PropertyGroup>
<VersionPrefix>1.0.0</VersionPrefix>
<TargetFrameworks>netcoreapp1.0</TargetFrameworks>
<OutputType>Exe</OutputType>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NETCore.App">
<Version>1.0.1</Version>
</PackageReference>
<PackageReference Include="Microsoft.NETCore.Sdk">
<Version>1.0.0-alpha-20160930-1</Version>
</PackageReference>
</ItemGroup>
<ItemGroup>
<Compile Include="**\*.cs" />
<EmbeddedResource Include="**\*.resx" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\MyLib\MyLib.csproj" />
</ItemGroup>
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>
Actual behavior
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" />
<PropertyGroup>
<OutputPath>bin\$(Configuration)</OutputPath>
</PropertyGroup>
<PropertyGroup>
<VersionPrefix>1.0.0</VersionPrefix>
<TargetFrameworks>netcoreapp1.0</TargetFrameworks>
<AssemblyName>MyApp</AssemblyName>
<OutputType>Exe</OutputType>
<PackageRequireLicenseAcceptance>false</PackageRequireLicenseAcceptance>
<AutoUnify>true</AutoUnify>
<DesignTimeAutoUnify>true</DesignTimeAutoUnify>
<ProjectLockFile>$(MSBuildProjectDirectory)/project.lock.json</ProjectLockFile>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NETCore.App">
<Version>1.0.1</Version>
</PackageReference>
</ItemGroup>
<ItemGroup>
<Compile Include="**\*.cs" Exclude="bin\**;obj\**;**\*.xproj;packages\**" />
<EmbeddedResource Include="**\*.resx" Exclude="bin\**;obj\**;**\*.xproj;packages\**" />
<EmbeddedResource Include="compiler\resources\**\*" Exclude="bin\**;obj\**;**\*.xproj;packages\**" />
<PackageReference Include="Microsoft.NETCore.Sdk">
<Version>1.0.0-alpha-20160930-1</Version>
</PackageReference>
</ItemGroup>
<ItemGroup Condition=" '$(TargetFrameworkIdentifier),Version=$(TargetFrameworkVersion)' == '.NETCoreApp,Version=v1.0' ">
<ProjectReference Include="..\MyLib\MyLib.csproj" />
</ItemGroup>
<PropertyGroup Condition=" '$(TargetFrameworkIdentifier),Version=$(TargetFrameworkVersion)' == '.NETCoreApp,Version=v1.0' ">
<DefineConstants>$(DefineConstants);NETCOREAPP1_0</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
<DefineConstants>$(DefineConstants);DEBUG;TRACE</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
<DefineConstants>$(DefineConstants);RELEASE;TRACE</DefineConstants>
<Optimize>true</Optimize>
</PropertyGroup>
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>
Notable changes needed:
- Drop the xml tag at the top. MSbuild doesn’t need it.
- Properties OutputPath, AutoUnify, DesignTimeAutoUnify, AssemblyName should be deleted. The SDK already includes these.
- Don’t know what PackageRequireLicenseAcceptance does but it seems very odd to have that. We should put that in the SDK if it’s needed.
- PackageReference items should be in the same itemgroup
- Excludes should be removed. If there are any default exclude globs missing, add that to the SDK.
- The ProjectReference shouldn’t be conditioned on the TFM when it’s the same as the one that the project is targeting.
- When it needs to be conditioned (because there are multiple TFs say) then it should use the $(TargetFramework) property for brevity and correctness.
- The constants for debug\release are already in the SDK - can be removed.
- The constants for TFMs should be added to the SDK.
As a principle, I think it’s fine to make these changes and force the SDK to react to the breaks since the SDK is mostly in shape now.
Issue Analytics
- State:
- Created 7 years ago
- Comments:10 (10 by maintainers)
Top Results From Across the Web
A successful file migration project in 7 steps - Atempo Blog
7 steps for a successful file migration project · 1 - Identify internal workflow needs · 2 - Map out the migration project...
Read more >Kicad 5 to 6 project migration file clean up - Software
I've updated a project from 5.x to 6 for the first time and it looks like I am able to remove some files...
Read more >Clean up your server instance before migration
Make a list of projects that you want to migrate, and remove projects you don't need before migrating. Check how much data you...
Read more >Clean up your Team Project Collection prior to migrating to ...
Clean up your Team Project Collection prior to migrating to VSTS · Delete old workspaces · Build results · Old team projects ·...
Read more >Deleting a Migration Project
In the migration projects maintenance screen (transaction RSMIGRATE), select the migration project and choose Migration Project Delete Migration Project.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
In general,
dotnet new
should exactly match:https://github.com/dotnet/sdk/blob/master/src/Templates/ProjectTemplates/CSharp/.NETCore/CSharpConsoleApplication/ProjectTemplate.csproj https://github.com/dotnet/sdk/blob/master/src/Templates/ProjectTemplates/CSharp/.NETCore/CSharpConsoleApplication/Program.cs
https://github.com/dotnet/cli/pull/4242 is cleaning up a few things here.
AssemblyName is gone. OutputPath is still in the new template, so it’s still in migrated projects. This can come separate.
This would need to happen in the sdk first and then someone can regenerate the defaults for migration. This entire block is necessary to match the project.json behavior, do we want to include all of these as defaults in the sdk?