NuGet包构建报错：本地正常编译，构建服务器提示GalaSoft找不到

Hey there, let's work through this frustrating build server issue you're hitting. I've dealt with similar NuGet dependency problems between .NET Standard and .NET Framework projects in CI environments, so here are actionable steps to fix the "GalaSoft" type/namespace error:

1. Ensure NuGet Restore Runs Before Build #

The most common culprit is that your build server isn't properly restoring NuGet packages before compiling.

• If you're using MSBuild, add the /t:Restore argument to your build command (e.g., msbuild YourSolution.sln /t:Restore;Build).
• If using .NET CLI, run dotnet restore first, followed by dotnet build.
• Double-check your CI pipeline configuration—some tools skip restore by default, or use outdated commands that don't handle .NET Standard packages correctly.

2. Verify NuGet Source Configuration #

Your local machine might have access to NuGet sources that the build server doesn't.

• Commit your local NuGet.config file to your code repository. This ensures the build server uses the same sources (like the official NuGet gallery) to fetch MVVMLightLibsStd10.
• If you're using a private feed, make sure the build server has credentials configured to access it (check your CI tool's NuGet source settings).

3. Check Package Version Consistency #

Mismatched package versions between your Core and Desktop projects can cause hidden dependency issues on build servers:

• Open both .csproj files and confirm the <PackageReference> for MVVMLightLibsStd10 uses the exact same version number (no wildcards like * or 5.4.x).
• Wildcards might resolve to different versions locally vs. on the server, breaking the GalaSoft namespace reference.

4. Clear NuGet Cache on the Build Server #

Corrupted or outdated cached packages on the server can lead to missing assemblies:

• Add a step in your build script to clear the NuGet cache:

  # For classic NuGet
  nuget locals all -clear
  # Or for .NET CLI
  dotnet nuget locals all --clear
  

• Run this before the restore step to ensure fresh packages are downloaded.

5. Validate .NET Framework Compatibility #

While .NET Framework 4.6.1 should support MVVMLightLibsStd10, double-check the package's minimum framework requirement:

• Confirm the package is compatible with 4.6.1 (it should be, but edge cases exist).
• If issues persist, try upgrading your Desktop project to .NET Framework 4.7.2—this improves compatibility with .NET Standard packages.

6. Confirm Correct Package Reference Method #

Make sure both projects are using NuGet package references (not manual DLL references):

• Avoid adding GalaSoft DLLs directly to your project (this works locally but fails on servers without the same file paths).
• Ensure your .csproj files use <PackageReference> entries instead of <Reference> for MVVMLight.

内容的提问来源于stack exchange，提问作者lightlike