我们有几个项目使用共享的通用库(内部使用,不对外公开)。这些项目是使用 Visual Studio 的 C# .net 语言编写的,被设置为解决方案。
总的来说,这种方法非常有效。通用库发布到内部的Nuget源中,两个项目都可以使用它,无论是在本地运行还是在构建服务器上。
但问题在于当我们想要修改通用库时,似乎唯一的测试方式是重新构建通用库、将更新的包发布到源中、升级Project A中的包(由于解决方案中有很多项目,这需要一段时间),然后进行测试。这个周期非常漫长。
理想情况下,我想找到一种方法,能够将通用库项目包含在Project A(或B)相同的解决方案中,并对库进行更改,然后作为一个解决方案运行和调试代码。但这样做需要花费很长时间。它需要逐个查看Project A中的所有csproj文件,将所有的引用从包引用更改为项目引用。尽管我已经尝试在csproj文件中使用条件语句,以便轻松切换使用本地项目或构建时使用Nuget包,但这似乎并不有效。Visual Studio似乎会因为引用而混淆,导致构建失败。
有其他的替代方法吗?我觉得这应该是一个比较常见的情况,那么有没有一种被广泛接受的典型方法来设置它,以便既可以使用Nuget包作为通用库,又可以连接它们并轻松进行调试呢?
针对@vernou的回答,这是我们尝试在csproj文件中使用条件属性来设置的。我们设置了一种配置类型来控制使用哪个引用。
实际上我们有一些项目使用经典的csproj引用格式(如上所示),还有一些使用较新的'包引用'格式来引用NuGet包。在这些情况下,第二个代码块可能会更像这样:
我们遇到的问题是,这似乎会让Visual Studio混淆。有时候在UI中会出现多个引用(这可能只是令人烦恼而非彻底破坏),但有时它似乎完全无法理解引用并拒绝构建或识别正在被引用的包,只会给出“可能缺少引用”的错误。
我们也尝试了在csproj内使用,但结果行为完全相同。
Solution A ---|
|----> Common Library (Nuget Package)
Solution B ---|
总的来说,这种方法非常有效。通用库发布到内部的Nuget源中,两个项目都可以使用它,无论是在本地运行还是在构建服务器上。
但问题在于当我们想要修改通用库时,似乎唯一的测试方式是重新构建通用库、将更新的包发布到源中、升级Project A中的包(由于解决方案中有很多项目,这需要一段时间),然后进行测试。这个周期非常漫长。
理想情况下,我想找到一种方法,能够将通用库项目包含在Project A(或B)相同的解决方案中,并对库进行更改,然后作为一个解决方案运行和调试代码。但这样做需要花费很长时间。它需要逐个查看Project A中的所有csproj文件,将所有的引用从包引用更改为项目引用。尽管我已经尝试在csproj文件中使用条件语句,以便轻松切换使用本地项目或构建时使用Nuget包,但这似乎并不有效。Visual Studio似乎会因为引用而混淆,导致构建失败。
有其他的替代方法吗?我觉得这应该是一个比较常见的情况,那么有没有一种被广泛接受的典型方法来设置它,以便既可以使用Nuget包作为通用库,又可以连接它们并轻松进行调试呢?
针对@vernou的回答,这是我们尝试在csproj文件中使用条件属性来设置的。我们设置了一种配置类型来控制使用哪个引用。
<ItemGroup Condition=" '$(Configuration)' == 'DebugWithLocalCommon' ">
<ProjectReference Include="$(CommonPath)Common.Project.Name\Common.Project.Name.csproj">
<Project>{11111111-1111-1111-1111-111111111111}</Project>
<Name>Common.Project.Name</Name>
</ProjectReference>
...
Multiple project references continue here
...
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)' != 'DebugWithLocalCommon' ">
<Reference Include="Common.Project.Name, Version=4.0.26.0, Culture=neutral, PublicKeyToken=1111111111111111, processorArchitecture=MSIL">
<HintPath>..\packages\Common.Project.Name.4.0.26\lib\netstandard2.0\Common.Project.Name.dll</HintPath>
</Reference>
...
Multiple package references continue here
...
</ItemGroup>
实际上我们有一些项目使用经典的csproj引用格式(如上所示),还有一些使用较新的'包引用'格式来引用NuGet包。在这些情况下,第二个代码块可能会更像这样:
<ItemGroup Condition=" '$(Configuration)' != 'DebugWithLocalCommon' ">
<PackageReference Include="Common.Project.Name">
<Version>4.0.26</Version>
</PackageReference>
...
Multiple package references continue here
...
</ItemGroup>
我们遇到的问题是,这似乎会让Visual Studio混淆。有时候在UI中会出现多个引用(这可能只是令人烦恼而非彻底破坏),但有时它似乎完全无法理解引用并拒绝构建或识别正在被引用的包,只会给出“可能缺少引用”的错误。
我们也尝试了在csproj内使用,但结果行为完全相同。