2017-06-27 4 views
0

Pendant des années, nous avons partagé notre code C# entre ces plates-formes en créant des projets pour chaque plate-forme dans un répertoire contenant tout le code source de ce projet. Comme nous avons ajouté de nouvelles plates-formes, si un fichier de code contenant ne compilait pas sur la nouvelle plate-forme, nous créerions une copie du fichier de code et le modifierions pour qu'il fonctionne sur la plate-forme prévue.Partage de code C# entre WPF, UWP, Phone 81 et Compact Framework

Un répertoire de projet pourrait ressembler à ceci

Application.Base 
    Applications.Base.CF.csproj 
    Applications.Base.WPF.csproj 
    Applications.Base.Phone81.csproj 
    Properties 
     AssemblyInfo.cs 
    Src 
     WidgetWPF.cs 
     WidgetPhone81.cs 
     Widget.cs 

Maintenant, je prends la même approche pour UWP et je suis en cours d'exécution dans cette question. Lors de l'ajout d'un nouveau projet pour UWP:

Application.Base 
    .... 
    Applications.Base.UWP 
    Properties 
     AssemblyInfo.cs 
     DSI.Applications.Base.UWP.rd.xml 
    ... 

Maintenant, quand je vais à ma solution WPF, je reçois une erreur de compilation du projet Applications.Base.WPF (événement si aucun fichier de projet UWP sont inclus dans le projet WPF) :

Votre projet ne fait pas référence à la structure «.NETFramework, Version = v4.6.1». Ajoutez une référence à ".NETFramework, Version = v4.6.1" dans la section "frameworks" de votre projet.json, puis réexécutez la restauration NuGet. DSI.Applications.Base

Après quelques tests A/B, je trouve que je peux corriger l'erreur en utilisant nuget pour supprimer la référence de l'UWP à Microsoft.NETCore.UniversalWindowsPlatform. Bien sûr, cela brise le projet UWP. Il n'y a aucun project.json présent du tout.

Y a-t-il une solution de contournement qui nous permettra de continuer le partage de code de cette manière? Refactoriser nos projets partagés pour accommoder toutes les plateformes serait un énorme fardeau - il y a beaucoup de projets partagés comme celui-ci - dont certains sont partagés avec d'autres plateformes (notre projet ASP.Net.)

+0

Pourriez-vous partager un [mcve] qui peut reproduire votre problème? D'ailleurs, avez-vous essayé de re-cibler ".Net Framework 4.6.1" comme l'a dit l'erreur? – Scavenger

+0

J'étudie la nouvelle cible. Il n'y a pas de fichier project.json comme référencé dans l'erreur. – jchristof

Répondre

0

Dans notre cas, l'obj dossier était le coupable. La construction de notre projet WPF a échoué seulement si des artefacts de la construction UWP étaient laissés dans le dossier obj. L'erreur m'a conduit à la question mais pas directement. Il n'y avait pas de fichier project.json dans le répertoire du projet comme erreur, mais dans le dossier obj il y avait un fichier project.assets.json. J'ai enlevé tout le contenu d'obj juste avant qu'une nouvelle construction de WPF et elle a réussi. Pour accommoder notre répertoire partagé, j'ai changé le répertoire intermédiaire (et bin) de la construction UWP en objUWP en modifiant le fichier projet. Je n'ai pas trouvé un moyen de le faire directement dans VS 2017, donc j'ai modifié le projet xml directement:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> 
    <PlatformTarget>AnyCPU</PlatformTarget> 
    <DebugSymbols>true</DebugSymbols> 
    <DebugType>full</DebugType> 
    <Optimize>false</Optimize> 
    <OutputPath>binUWP\Debug\</OutputPath> 
    <BaseIntermediateOutputPath>objUWP\</BaseIntermediateOutputPath> 
    <DefineConstants>DEBUG;TRACE;NETFX_CORE;WINDOWS_UWP</DefineConstants> 
    <ErrorReport>prompt</ErrorReport> 
    <WarningLevel>4</WarningLevel> 
    </PropertyGroup>