标签: multi-targeting

我已经将Windows服务构建为"任何CPU".但是,当我在64位机器上运行时,它以32位运行.我该如何解决？我使用的是.NET和C#,我的操作系统是Windows 2008 R2.

如果我在x64中构建它,它会以64位模式正确加载.但是,"Any Cpu" - 这就是我想要的 - 加载32位,即使它运行的机器完全支持64位.

编辑以根据反馈添加更多信息

我们确实有第三方工具以及引用c ++托管程序集.这些可能是也可能不是为任何CPU构建的.事实上我知道c ++托管程序集只是为x86构建的.然而,奇怪的是,如果我专门指定x64,该进程将启动并在x64中工作.如果框架试图加载c ++托管程序集,它将失败.我不介意这一点,因为在代码中,如果我们以64位模式运行,我们不会加载32位托管++程序集.可能是因为构建数据,因为这里有32位程序集,它应该将启动过程(在本例中是一个Windows服务程序集)标记为x86？

我正在尝试构建大约600个项目,有些是.net 2.0,有些是3.5.我正在使用Windows 2003企业版32位与所有最新的Windows更新.

当maxcpucount为1时构建正常.如果我试图提高性能,则会出现引用错误.当我查看错误发生位置的项目引用时,它们应该按顺序构建.

下面我提供了一个导致构建被破坏的错误的示例.不要挂在项目名称或相关路径上,因为我已经改变了这一点,所以我不会对我的雇主遇到麻烦.

这就像当多个核心构建解决方案时,相对项目引用无法正确解析.

"C:\SVN\MyLibrary\MyLibrary.csproj" (default target) (15) ->
   "C:\SVN\FileProcessor\FileProcessor.csproj" (default target) (17) ->
   (ResolveProjectReferences target) ->
     C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets : warning : The referenced project '..\..\Manager\Manager.csproj' does not exist.


   "C:\SVN\MyLibrary\MyLibrary.csproj" (default target) (15) ->
   "C:\SVN\FileProcessor\FileProcessor.csproj" (default target) (17) ->
   (CoreCompile target) ->
     FileProcessor.cs(18,39): error CS0234: The type or namespace name 'Manager' does not exist in the namespace 'TheNamespace' (are you missing an assembly reference?)

我没有在解决方案文件上使用msbuild.我正在使用通配符选择所有csproj文件,然后将它们提供给msbuild.对于开发,我们有多个解决方案,我们用于系统的不同组件.95%是项目引用,唯一的二进制引用是核心实用程序库

在Visual Studio 2010中以.NET框架的早期版本为目标需要哪些步骤？

我安装了Visual Studio和.NET 2.0 SDK(从这里开始),但只有.NET 4.0位于可用框架列表中.

我错过了什么？

我有一个需要面向 .NET 3.5 和 .NET 4.0 的类库项目，现在完成的方式是为每个目标框架创建单独的项目并将每个项目中的文件链接到同一源的典型方法。

我想利用 .NET Core 项目推出的新 csproj 格式，因为使用新 csproj 格式进行多目标处理要简单得多。

我创建了一个新的类库 (.NET Core) 项目，并开始尝试移植现有的库。

我真的不需要以 .netcoreapp2.0 为目标，所以我的目标框架如下所示

<PropertyGroup>
  <TargetFrameworks>net35;net40</TargetFrameworks>
</PropertyGroup>

我有以下代码块来帮助解决.NET 3.5中新的 csproj 格式的奇怪问题。

<PropertyGroup>
  <FrameworkPathOverride Condition="'$(TargetFramework)' == 'net35'">C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v3.5\Profile\Client</FrameworkPathOverride>
</PropertyGroup>

到目前为止，一切都很好。事情开始走下坡路的是我的类库有 WPF 控件。我收到编译错误，因为它找不到System.Windows其他 WPF 相关项目。

我发现我可以添加对其他 Windows 程序集的引用，因此我添加了以下内容

<ItemGroup>
  <Reference Include="PresentationFramework" />
  <Reference Include="PresentationCore" />
  <Reference Include="WindowsBase" />
</ItemGroup>

这消除了我的大部分错误，但现在我遇到了类似的错误The name 'InitializeComponent' does not exist in the current context

我见过一些提供不同构建的框架; 例如,他们可能提供32位和64位版本,或者他们可能提供针对.NET 2.0,3.5和4.0的版本

我有一个可以在.NET 3.5上运行的库,但是我不确定什么是最好的发布策略.

我想知道创建多个框架目标有什么好处,以及具体针对32位和64位CPU有什么好处.

如果我要走多目标的道路,是否有任何关于如何实现这一目标的好教程？

如何在Visual Studio 2010中的WPF和Silverlight项目之间共享文件？

我只想在构建过程之前运行我的 powershell 脚本一次。在我看来，这应该很容易完成，只需在 PreBuildEvent 之前调用脚本即可。嗯，它确实适用于普通项目。

但是，对于多目标项目？在针对所有目标框架的每次构建之前，脚本将被多次调用。

这是我的项目文件，其中我针对 3 个框架：

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net40;net45;netstandard1.4</TargetFrameworks>
    <AssemblyName>abc</AssemblyName>
    <Version>1.0.0</Version>
  </PropertyGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'net40' ">
    <Reference Include="System" />
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'net45' ">
    <Reference Include="System" />
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>
  <Target Name="PreBuild" BeforeTargets="PreBuildEvent">
    <Exec Command="PowerShell -ExecutionPolicy Unrestricted -File script.ps1/>
  </Target>
</Project>

当我构建项目时，PreBuild 目标被调用了 3 次。

到目前为止，我已经尝试过：

1) 起初，我猜测构建是按顺序进行的，所以我向目标添加了一个条件：

  <Target Name="PreBuild" BeforeTargets="PreBuildEvent" Condition=" '$(TargetFramework)' == 'net40' ">
    <Exec Command="PowerShell -ExecutionPolicy Unrestricted -File script.ps1/>
  </Target>

，这不起作用。事实证明，多目标构建是同时进行的。有时，net40 的构建会更晚，所以我的脚本没有在所有构建之前运行。

2）然后我尝试使用环境变量进行同步，但也没有成功。似乎构建没有共享环境变量。

3) 最后，我转向其他 …

我正在开发一个开源库，它主要由一个针对 .NET Standard 2.0 的类库项目组成。最重要的是，我还实现了一个控制台应用程序，它是该库的 CLI。控制台项目（由于历史原因）仅针对 .NET Framework 4.6.2。

现在我想知道为了让这个控制台应用程序可供社区使用，最佳实践是什么。从最广泛的层面来看，我看到两种可能性：

1. 将控制台应用程序作为单独的 NuGet 发送。
2. 将控制台应用程序与类库放在同一个 NuGet 中，因为它只是一个次要的附加组件，并不能证明自己的包是合理的。

从历史上看，我一直使用第二种方法，但考虑到类库可以在多目标场景中使用，我不再确定。也许将控制台应用程序分离在自己的 NuGet 中会更干净，这样它对完整 .NET 框架的依赖就很清楚。

不管怎样，我想知道控制台exe在NuGet的文件结构中属于哪里。从历史上看，我一直把它放在下面，但此页面上tools\net462有关该文件夹的评论让我不安全：tools

可通过程序包管理器控制台访问 Powershell 脚本和程序

我不一定想象有人使用包管理器控制台中的 CLI。相反，它会在某个 shell 的某个地方用作独立的 exe。