5

Aktualizacja: Odnosi się to do przestarzałego zestawu podstawowych narzędzi .net zbudowanych wokół project.json, to pytanie i jego odpowiedzi są bardzo ograniczone w aktualnych zestawach narzędzi .net, takich jak Visual Studio 2017+.Utwórz projekt z jednym źródłem z pełnymi zespołami jądra .net, PCL i dotnet zbudowanymi z tego samego źródła C#?

pomocą programu Visual Studio 2015 Update 3, Próbuję dowiedzieć się obecne ograniczenia, które istnieją, która przeszkadza mi w następujący sposób:

  1. Dla pojedynczej C# kodzie, skompilować pełną .NET wersję szkieletową i wersję PCL oraz bibliotekę rdzeni .net z tych samych źródeł.

  2. Rozwiązanie dir solutiondir\ będzie zawierać src\ dir który zawiera projectdir\ (Solutiondir\src\projectdir).

  3. Projectdir będzie zawierać HelloWorldPCL klasy biblioteki, który jest zbudowany jako classic .net PCL projektu, a także z innymi celami ramowych, jak również.

  4. Od samego Projectdir samo HelloWorldPCL będą również sporządzane dla .net 4.6 projektu.

  5. Od samego Projectdir samo HelloWorldPCL będą również sporządzane dla .net core.

  6. Wszystkie zespoły wyjściowych powyżej będą dzielić dostęp do jednego zestawu kodu C#, które mogą mieć pewne #if DOTNET i #if NET46 i #if PCL definiuje warunkowe obsłużyć rzeczy, które nie są dostępne w różnych ram/środowiskach.

Dotychczas mogę zrobić większość z powyższych, ale gdy próbuję mieć Projectdir zawierać .net core artefakt jak project.json lub HelloWorldCore.xproj, IDE daje mi wiele błędów, gdy próbuję utworzyć oddzielne .csproj i .xproj projekty w tym samym folderze, więc wydaje się, że nie jest to właściwa droga.

Przy pracy .csproj projektu, kiedy wprowadzić .xproj i project.json na dysku, ale nie dodałem je do samego rozwiązania, są one po prostu siedzi tam na dysku obok prawdziwych źródeł projektu, mam pakiet Nuget błąd przywracania, który można usunąć tylko poprzez usunięcie pliku project.json, więc wyraźnie nie można mieć katalogu .csproj w katalogu projektu, a także mieć folder project.json. Należy wybrać pomiędzy trybem project.json (.net core styl projektu) i .csproj (klasyczny styl projektu C#).

I zbudowali "broken" codebase, który pokazuje niemożność korzystania folder zawierający zarówno .csproj i project.json a następnie stara się zbudować projekt csproj i project.json bez ich ingerencji:

https://bitbucket.org/wpostma/helloworldcoreandpcl

Pytanie: czy istnieje JAKIKOLWIEK sposób, aby zbudować projekt z jednego zestawu plików źródłowych C# i mieć jako cel, pełny zbiór .net 4.6, a także natywną bibliotekę klas , a także PCL jako sembly, który może być kierowany na konkretny profil .net?

Zarzut: może słusznie zapytać? „Nie należy po prostu użyć jednego PCL i zrobili z nim, i zapomnieć kierowania pełny .net lub utworzenia oddzielnej biblioteki dll .net core klasa”. Może gdyby kod mógł zostać zbudowany raz, z jednego źródła, bez żadnych warunkowych definicji, i bez żadnych różnic w funkcjonalności oraz gdyby ograniczenia narzucone przez profil najniższego wspólnego mianownika PCL "" standardowego standardu "były wystarczające, . Ale co z przypadkami, w których nie jest to możliwe?

Czy potrzebujemy jakiegoś skomplikowanego procesu kompilacji, w którym kopiujemy pliki projektu lub przenosimy kod źródłowy dookoła, aby uzyskać pojedynczy plik źródłowy docelowy dla wielu plików .net nerdvana? Czy mogę przeoczyć alternatywne rozwiązania?

Aktualizacja: Wydaje się, że jest problem z Visual Studio IDE, który uniemożliwia bezpośrednio dodając odwołanie do biblioteki klas w roztworze, gdy go zbudować z project.json zamiast stosowania .csproj. Jednak rozwiązanie poniżej określone przez Jona wskazuje, że powinieneś zbudować swój projekt, a następnie zbudować pakiet nuget z dotnet pack. Jeśli spojrzysz na moje zmodyfikowane demo, możesz w pliku pack.cmd opisać kroki, których użyłem do spakowania pakietu nuget, a następnie lokalnie "opublikować" go do pliku (lokalnego katalogu) nuget do mojego osobistego użytku.

+0

Dla bardziej konkretnego przykładu rozważ ten kod źródłowy, w którym próbuję tworzyć natywne obiekty biblioteki klas .net, w bazie kodowej, która obecnie ma podwójne PCL i rozwiązania pełno-sieciowe, co daje dwie trzecie tego, co chciałem zrobić w pytaniu powyżej ... https://github.com/wpostma/fhir-net-api –

+2

Dlaczego mają trzy różne pliki projektu? Myślę, że możesz to wszystko zrobić z jednym 'project.json', który obsługuje trzy różne frameworki. (Możesz też mieć różne opcje kompilacji dla różnych frameworków, ...) –

+0

Zobacz https://stackoverflow.com/questions/36148363, aby uzyskać pomoc dotyczącą kierowania na PCL z projektu.json. –

Odpowiedz

6

Chciałbym spróbować zastosować podejście czysto project.json. Na przykład tutaj znajduje się plik project.json, który zbuduje pojedynczy pakiet obsługujący netstandard1.0, profil PCL 328 i .NET 4.6 - z każdą konfiguracją definiującą własne symbole, dzięki czemu można uzyskać kod warunkowy.

{ 
    "version": "1.0.0", 

    "frameworks": { 
    "net46": { 
     "buildOptions": { 
     "define": [ "NET46" ] 
     } 
    }, 

    "netstandard1.0": { 
     "buildOptions": { 
     "define": [ "CORE" ] 
     }, 
     "dependencies": { 
     "NETStandard.Library": "1.6.0" 
     } 
    }, 

    ".NETPortable,Version=v4.0,Profile=Profile328": { 
     "buildOptions": { 
     "define": [ "PCL" ] 
     }, 
     "frameworkAssemblies": { 
     "mscorlib": "", 
     "System": "", 
     } 
    } 
    } 
} 

Następnie wystarczy użyć dotnet pack aby utworzyć pakiet Nuget. (Po dodaniu wszystkich innych metadanych itp.)

+0

@WarrenP: Spróbuje się powielić. Chociaż zauważ, że w tym samym rozwiązaniu, zazwyczaj używam zależności '" cel ":" projekt "', aby uniknąć konieczności określania numeru wersji. –

+0

@WarrenP: Dlaczego masz cztery różne projekty w swojej próbce? Ułatwiłoby to zrozumienie, co się dzieje, gdybyś miał dwie: bibliotekę klasową z project.json, jak na moją odpowiedź, a następnie aplikację konsolową próbującą ją pochłonąć ... (W szczególności, który projekt zawodzi? brzmi: może to być problem z projektami csproj, które nie są w stanie pochłonąć projektów project.json.Należy spróbować zbudować wszystko na project.json lub spakować bibliotekę klas do pakietu nuget, umieścić w lokalnym źródle pakietu i uzależnić na tym.) –

+0

@WarrenP: Cóż, sprawdziłbym, czy wynikowy project.json jest tym, czym chcesz go mieć. Trochę staranności na wczesnym etapie może wypłacić dywidendy w późniejszym utrzymaniu. –

1

Możesz użyć xproj i csproj razem z różnymi plikami project.json. Zrobiłem wpis na blogu na temat, który powinieneś sprawdzić: http://stackify.com/using-both-xproj-and-csproj-with-net-core/

Zasadniczo tworzysz projectname.project.json, który csproj odbiera, a następnie project.json, którego używa xproj. Wydaje się działać!

+0

Dzięki. To przydatna technika! –

Powiązane problemy