Azure WebApp使用VS持续交付时出现程序集错误

Hey there, as someone who’s tangled with plenty of CI/CD quirks in web apps, let’s break down why your manual publish works flawlessly but your Visual Studio Online (VSO) build/publish is throwing assembly errors—even though you see the Storage assembly in the bin folder via Kudu.

1. Check NuGet Dependency Restoration in Your Build Definition #

Manual publishing in Visual Studio automatically handles NuGet package restoration, but VSO builds rely on explicit setup. Here’s what to verify:

• Ensure your build definition includes a NuGet restore step before the core build task. If it’s missing, add it and confirm it targets all relevant projects in your solution.
• Double-check that the NuGet package sources configured in the build step match what you use locally. If your Storage assembly comes from a private or local package feed, VSO might not have access to it—you’ll need to add that feed to your build’s package source settings.

2. Confirm Project References & Build Scope #

If Storage is a local project reference (not a NuGet package):

• Make sure the Storage project is included in your VSO build definition’s solution/project list. Sometimes CI builds only target specific projects, and skipping the Storage project means it won’t be built alongside your web app—leading to assembly errors during publish.
• Check the reference properties in your web app project: right-click the Storage reference → Properties → ensure Copy Local is set to True. This guarantees the assembly gets copied to the output directory during build, not just during manual publish.

3. Align Build & Publish Configurations #

Mismatched configurations (Debug vs. Release) are a common culprit here:

• Confirm your VSO build uses the same configuration (e.g., Release) that you use for manual publishing. Different configurations might have conditional dependencies, compilation settings, or output paths that break the assembly reference.
• Peek into your web app’s .csproj file for configuration-specific reference conditions. For example, a reference might only be included in Debug mode—explaining why Release builds in VSO fail.

4. Dig Into Build & Deployment Logs #

The build logs will tell you exactly what’s wrong—don’t skip this step:

• In VSO, navigate to your failed build and view the build logs. Look for specific errors like The type or namespace name 'Storage' could not be found—this points to a missing reference during the build phase, not deployment.
• Note that the Storage assembly in the bin folder via Kudu might be leftover from a previous manual publish, not the failed VSO deployment. Clean the deployment slot first, then run the VSO build again to see if the assembly is actually being deployed correctly.

5. Clear Build Caches #

Old artifacts or cached dependencies can cause unexpected issues:

• In your VSO build definition, enable the Clean workspace option (under the Get sources tab). This ensures the build agent starts with a fresh copy of your code, avoiding cached old assemblies or incomplete dependencies.
• You can also add a command line step to delete the bin and obj folders before the build runs, using a command like:

  rm -rf $(Build.SourcesDirectory)/YourWebApp/bin $(Build.SourcesDirectory)/YourWebApp/obj
  

  (Adjust the path to match your project structure.)

6. Validate Project File HintPaths #

If your Storage assembly is referenced via a local file (not NuGet or project reference):

• Open your web app’s .csproj file and look for the <Reference> element for Storage. Ensure the HintPath points to a location that exists on the VSO build agent. For example, if you’re referencing a local assembly in a lib folder, confirm that folder is checked into source control and the path is correct relative to the project.

Work through these steps one by one, starting with the build logs—they’re your most reliable clue to fixing this issue!

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