好吧,它看起来像UWP和.NET Core项目可以使用相同的project.json。它的“框架”一节的样子:
"frameworks": {
"netstandard1.3": {},
"uap10.0": {
"dependencies": {
"Microsoft.NETCore.UniversalWindowsPlatform": "5.2.2"
}
}
},
因为UWP项目都有自己的csproj文件,这导致3倍号楼的DLL:project.json导致netstandard1.3和uap10.0文件夹显示在斌/调试(和将生成的DLL放置在那里)当构建.NET Core项目时,而UWP项目本身在bin/Debug中构建另一个DLL。
bin/Debug/uap10.0/My.dll是垃圾,它不能包含任何UWP专用代码(因为通用Windows引用在.NET Core项目中不可用),因此我没有在项目中定义WINDOWS_UWP .json的“uap10.0”部分。
但是,UWP csproj文件确实定义了WINDOWS_UWP,并且该项目中提供了通用Windows。所以,当UWP项目被建成,它实际上只使用了这一点:
"uap10.0": {
"dependencies": {
"Microsoft.NETCore.UniversalWindowsPlatform": "5.2.2"
},
(如果这个代码是在project.json丢失,UWP项目将无法生成)。 project.json的其余部分(主要针对“netstandard1.3”目标)对构建过程没有任何影响。
所以我依靠的事实是,我可以在project.json中定义条件指令(在这种情况下是WINDOWS_UWP),但也在csproj文件中,因此在处理使用相同项目的UWP项目时会获得额外结果.json文件作为.NET Core项目。在某种程度上,UWP csproj作为另一个在构建过程中与真实项目合并的project.json。
是的,我得到了一个额外的DLL bin/Debug/uap10.0/My.dll这是没有用的(只是浪费编译时间),但我会只选择那些有用的输出所以在我的特殊情况下这不是问题。
恐怕我没有提到(为了简洁起见)实际上有更多更老的Visual Studio和.NET Framework的目标(例如.NET Framework 2.0),并且这些目标不能使用共享库的概念。所以我实际上不能用这种方式重组我的项目。 – Alex