Support additional target frameworks such as for Xamarin, UWP, etc

[clairernovotny]

The current SDK is missing what should be static reference info for its property groups. That makes using multi-targeting much harder and puts more useless info in the csproj.

For example: https://github.com/onovotny/Zeroconf/blob/367c63d21dacf841c204b13ea178fdce174bb93b/Zeroconf/Zeroconf.csproj#L3

All of those property groups should be in the SDK (with the possible exception of the TargetPlatformMinVersion attribute for UAP, but even there it can default to 10.0.10240 easily).

What should be in the SDK:

• All "inbox" TFM's
  • All PCL profiles with standard aliases (portable-net45+win8+wpa81+wp8), etc. Bonus points for parsing and allowing any order of matching frameworks (via NuGet core logic in task?)
• All installable frameworks (wp8, win, wpa, sl, uap, all Xamarin tfms)

Those property groups should include the appropriate LanguageTargets that point to the correct version to ensure a proper build. For a user, it should "just work".

I think it's ok that some TFM's cannot be built with dotnet build, but require msbuild so that it picks up the correct MSBuildExtension paths for built-in targets. Bonus points for an error/warning if the appropriate targets is missing telling the user to install foobar SDK to get it. Clearly some of these builds will only work on Windows too, but that's ok.

[dsplaisted]

As part of this, we should also include the appropriate implicit framework references such as System, System.Core, etc for these platforms, like we currently do for .NET Framework.

[clairernovotny]

Tizen should also be supported as a new and important member of the ecosystem.

[clairernovotny]

I am attempting to do this in a NuGet package for RTW. Maybe some of it can be incorporated back here? https://github.com/onovotny/MSBuildSdkExtras

It supports all legacy PCL profiles except the XBox360 ones... Yes, WP7 and SL4 profiles work ;)

Order doesn't matter of the Portable- TFM's. What does matter is that you can't specify optional ones -- i.e., no Xamarin TFM's in the Portable section. NuGet ignored those anyway.

Feedback is appreciated, as is any direction as to how to incorporate into the main SDK.

[niemyjski]

Any updates on this?

[weitzhandler]

Is there a way to upgrade WPF projects to the new csproj format?

[thomaslevesque]

Is there a way to upgrade WPF projects to the new csproj format?

There's no official support for it yet, but have a look at this project, which managed to make it work.

[weitzhandler]

I upgraded the project and it works fine, here's my setup (no need to manually add all xaml and cs files):

<Project Sdk="Microsoft.NET.Sdk">

  <!-- Project properties -->
  <PropertyGroup>
    <LanguageTargets>
      $(MSBuildExtensionsPath)\$(VisualStudioVersion)\Bin\Microsoft.CSharp.targets
    </LanguageTargets>
    <TargetFramework>net47</TargetFramework>
    <OutputType>WinExe</OutputType>
    <AssemblyName>MyWpfProject</AssemblyName>
    <RootNamespace>MyWpfProject</RootNamespace>
    <ApplicationIcon />
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <LangVersion>latest</LangVersion>
    <DebugType>full</DebugType>
    <DebugSymbols>true</DebugSymbols>
  </PropertyGroup>

  <!-- NuGet packages -->
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNet.WebApi.Client" Version="5.2.3" />
    <PackageReference Include="Newtonsoft.Json" version="10.0.3" />
    <PackageReference Include="Prism.DryIoc" Version="6.3.0" />
    <PackageReference Include="PropertyChanged.Fody" version="2.2.2" />
    <PackageReference Include="PropertyChanging.Fody" version="1.28.0" />
    <PackageReference Include="System.Collections.Immutable" version="1.4.0" />
    <PackageReference Include="System.ComponentModel.Annotations" version="4.4.0" />
  </ItemGroup>

  <!-- mandatory packages -->
  <ItemGroup>
    <Reference Include="PresentationCore" />
    <Reference Include="PresentationFramework" />
    <Reference Include="ReachFramework" />
    <Reference Include="System.Net" />
    <Reference Include="System.Printing" />
    <Reference Include="System.Xaml" />
    <Reference Include="WindowsBase" />
  </ItemGroup>

  <ItemGroup>
    <!-- App.xaml -->
    <ApplicationDefinition Include="App.xaml">
      <SubType>Designer</SubType>
      <Generator>MSBuild:UpdateDesignTimeXaml</Generator>
    </ApplicationDefinition>

    <!-- XAML elements -->
    <Page Include="**\*.xaml" Exclude="App.xaml">
      <SubType>Designer</SubType>
      <Generator>MSBuild:UpdateDesignTimeXaml</Generator>
    </Page>
    <Compile Update="**\*.xaml.cs" SubType="Code" DependentUpon="%(Filename)" />

    <!-- Resources -->
    <EmbeddedResource 
      Update="Properties\Resources.resx" 
      Generator="ResXFileCodeGenerator" 
      LastGenOutput="Resources.Designer.cs" />
    <Compile 
      Update="Properties\Resources.Designer.cs" 
      AutoGen="True" 
      DependentUpon="Resources.resx" 
      DesignTime="True" />    

    <!-- Settings -->
    <None 
      Update="Properties\Settings.settings" 
      Generator="SettingsSingleFileGenerator" 
      LastGenOutput="Settings.Designer.cs" />
    <Compile 
      Update="Properties\Settings.Designer.cs" 
      AutoGen="True" 
      DependentUpon="Settings.settings" />    

    <!-- Assets -->
    <Resource Include="Fonts\*.otf" />
    <Resource Include="Images\*.png" />
  </ItemGroup>        

  <Import Project="..\Shared\Shared.projitems" Label="Shared" />
</Project>

Just bare in mind that there is an issue that happens when adding new files, the newly added files are added separately un-nested. To fix it, you'll have to open the csproj file after each new added file, and delete the explicit file inclusion. After project reload the files will be nested again.

[xperiandri]

What about ASP.NET Classic?

[weitzhandler]

@xperiandri are you serious?

[xperiandri]

Me not, but enterprise yes Is it a big deal to fix MVC 4-5 project launch on IIS?

[weitzhandler]

Sorry I thought you were taking about pre-MVC

[danielmeza]

@clairernovotny This should target .net 5 preview 3!

[jnoyola]

From what I can tell from the release notes, it looks like this didn't make it into preview 3, is that correct? Is there any new timeline we can look forward to? 🙂

[riverar]

Did this ship? @clairernovotny

[mungojam]

Did this ship? @clairernovotny

I've been using it successfully with a xamarin android project, though I believe it is officially in preview as part of MAUI.

You need to add it as an optional workload. You can then do dotnet new to see what a new style project looks like

[marcpopMSFT]

We'll not be adding all the old platforms but going forward with Maui, we believe the goals of this issue were covered so closing.

[hawkerm]

@marcpopMSFT trying to multi-target to build on existing stable UWP while testing out the new WindowsAppSDK right now. I'd assume I could try going like this:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFrameworks>net7.0</TargetFrameworks>
        <TargetFrameworks Condition="$([MSBuild]::IsOSPlatform('Windows')) or '$(EnableWindowsTargeting)' == 'true'">$(TargetFrameworks);net7.0-windows10.0.18362</TargetFrameworks>
        <TargetFrameworks>$(TargetFrameworks);uap10.0.17763</TargetFrameworks>

But this causes a failure (in VS 2022 17.4.4):

1>C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(1229,5): error MSB3644: The reference assemblies for UAP,Version=v10.0.17763 were not found. To resolve this, install the Developer Pack (SDK/Targeting Pack) for this framework version or retarget your application. You can download .NET Framework Developer Packs at https://aka.ms/msbuild/developerpacks

So, believe there's still a gap here?

[borrrden]

Definitely a gap. Seems like trying to rush Xamarin and UWP into sunset mode by making it harder and harder to build for them. I think the only way to multi target library for both legacy Xamarin and modern .NET mobile support is to use MSBuild.Sdk.Extras, which literally is only handled correctly by VS4Win. VS4Mac, Jetbrains rider, dotnet CLI and C# dev kit for VSCode all fail on this.