New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
onovotny opened this Issue Dec 14, 2016 · 11 comments

Comments

Projects
None yet
9 participants
@onovotny
Member

onovotny commented Dec 14, 2016

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.

@srivatsn srivatsn added the Bug label Dec 21, 2016

@srivatsn srivatsn added this to the 1.0 RTM milestone Dec 21, 2016

@dsplaisted dsplaisted changed the title from PropertyGroup's missing for TFM's to Support additional TFMs such as for Xamarin, UWP, etc Jan 4, 2017

@dsplaisted dsplaisted changed the title from Support additional TFMs such as for Xamarin, UWP, etc to Support additional target frameworks such as for Xamarin, UWP, etc Jan 4, 2017

@dsplaisted

This comment has been minimized.

Member

dsplaisted commented Jan 4, 2017

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.

@onovotny

This comment has been minimized.

Member

onovotny commented Jan 17, 2017

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

@onovotny

This comment has been minimized.

Member

onovotny commented Feb 12, 2017

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

This comment has been minimized.

niemyjski commented Sep 30, 2017

Any updates on this?

azabluda added a commit to azabluda/InfoCarrier.Core that referenced this issue Oct 20, 2017

Add quick and dirty WcfSample.Android application.
We have to wait for dotnet/sdk#491 (as per http://www.natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/) until we get better support for Xamarin.Android projects in dotnet/sdk. For now the project is excluded from the build. Enthusiasts may reactivate it in VS - Build - Configuration Manager.

azabluda added a commit to azabluda/InfoCarrier.Core that referenced this issue Oct 20, 2017

Add quick and dirty WcfSample.Android application.
We have to wait for dotnet/sdk#491 (as per http://www.natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/) until we get better support for Xamarin.Android projects in dotnet/sdk. For now the project is excluded from the build. Enthusiasts may reactivate it in VS - Build - Configuration Manager.
@weitzhandler

This comment has been minimized.

weitzhandler commented Dec 8, 2017

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

@thomaslevesque

This comment has been minimized.

thomaslevesque commented Dec 8, 2017

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

This comment has been minimized.

weitzhandler commented Dec 8, 2017

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

This comment has been minimized.

xperiandri commented Dec 21, 2017

What about ASP.NET Classic?

@weitzhandler

This comment has been minimized.

weitzhandler commented Dec 21, 2017

@xperiandri are you serious?

@xperiandri

This comment has been minimized.

xperiandri commented Dec 21, 2017

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

@weitzhandler

This comment has been minimized.

weitzhandler commented Dec 21, 2017

Sorry I thought you were taking about pre-MVC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment