我在工作中继承了一个新的 C# 项目，我一直在阅读源代码并为它构建 Azure Dev-ops 管道
它有大约多个后台线程和一个服务
我对 Dev-ops Pipelines 还是有点陌生，但我不是一个白痴
简直就是个白痴
有一个名为 [name of service]service.cs 的模块
它构建在 x86 构建平台上，其余构建在任何 CPU 上
（我还没有编写任何代码，除了错误修复以使其运行
我将配置应用程序设置从一个模块复制到第二个模块，以便
配置管理器会看到它
我添加了一个布尔值
而已）
我的逻辑基于问题所在；是它在我的机器上构建得很好，而不是在 Dev-ops 上
到这里的这一点信息
并注意我不能将它切换到任何 cpu 并且它不会构建到 86
只是为了确认
该页面不仅有一个包含引用的 using 语句。
中断它的行调用包含命名空间的新语句，因此即使 using 不存在，它也应该没问题
对我来说，这意味着 Dev-ops 环境没有构建 [name of service]service.cs 项目
是 x86 构建模块在管道中引发错误
我主要是自学成才，并且一直在阅读有关此模块的背景信息
我相信这与该模块的代码库有关，该模块有多个 Intptr 和对非托管代码的引用
//structure for the Process32First API
[StructLayout(LayoutKind.Sequential)]
private struct PROCESSENTRY32
{
public uint dwSize;
public uint cntUsage;
public uint th32ProcessID;
public IntPtr th32DefaultHeapID;
public uint th32ModuleID;
public uint cntThreads;
public uint th32ParentProcessID;
public int pcPriClassBase;
public uint dwFlags;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 260)]
public string szExeFile;
}
我必须阅读非托管代码与托管代码是什么，我想我理解
据我所知，这种差异更符合我的逻辑
所有这些要问
我怎样才能像我的机器一样天蓝色地构建这个
在我看来，我的管道的上下文也会添加到这个对话中，所以为了这个目的
