TempProject breaks when custom NuGet source used

[hazzinator1]

Hi guys,

We have a custom NuGet source for our company sitting in a WorkHub_NuGet location on our tenant. The problem is that when building our solution that uses Metalama, we suddenly get errors with the TempProject.cs project saying it is unable to load service index. This has now happened to multiple devs in our team, with another issue being that Microsoft.CodeAnalysis.CSharp Nuget could not be found. My hunch is that this "service index" issue is actually hiding the real issue, which is that Microsoft.CodeAnalysis.CSharp is taken from our custom feed (where it doesn't exist) for some reason rather than nuget.org.

Both of these issues are fixed by the following:

1. Navigate to where the TempProject.cs is (AppData/Local/Temp/Metalama/AssemblyLocator/{LatestDate}/{VersionId}/TempProject.cs
2. Open it in Visual Studio
3. Manage Nuget packages for project
4. Find the installed Microsoft.CodeAnalysis.CSharp and uninstall it
5. Reinstall it using the normal nuget.org web source

Obviously this setup is unique to our own project, and we do have a workaround for now, however it would be good to get some clarification from the Metalama team on whether this is something going wrong on your side.

[prochan2]

Hello, thank you for reaching out.

Could you please provide more details on how your environment is configured regarding the NuGet feed setup so we can reproduce the issue?

[hazzinator1]

It's a very simple setup, just contains two packages that we've added some extra functionality into specific to our project.

It contains Microsoft.Exchange.WebServices and our own custom extension of the MsgKit project that we've called MsgKitExt. You could probably just install the normal MsgKit if you wanted to test with that particular project.

[prochan2]

And how is this custom NuGet feed configured in your projects? I'm trying to figure out how it can affect the build of the AssemblyLocator's TempProject.

[gfraiteur]

Could you pls attach or send is privately the *.binlog file under (AppData/Local/Temp/Metalama/AssemblyLocator/{LatestDate}/{VersionId}?

[hazzinator1]

And how is this custom NuGet feed configured in your projects? I'm trying to figure out how it can affect the build of the AssemblyLocator's TempProject.

This is a rough depiction of our project structure:

• MainProject: Contains program.cs and dependency injection stuff
  • Project reference: SideProject
  • Project reference: CustomProject
  • Nuget: Metalama.Framework 2024.2.20
  • Nuget: Metalama.Extensions.DependencyInjection 2024.2.20
• SideProject: uses the dependency injection aspect to add in dependencies on a class without us needing to do it ourselves
  • Nuget: Metalama.Extensions.DependencyInjection 2024.2.20
• ProjectUsingCustomFeed:
  • Nuget (from custom feed): Microsoft.Exchange.WebServices
  • Nuget (from custom feed): MsgKit

Could you pls attach or send is privately the *.binlog file under (AppData/Local/Temp/Metalama/AssemblyLocator/{LatestDate}/{VersionId}?

I've sent you an email with the binlog attached

[gfraiteur]

Thank you.

I'm puzzled that access to https://pkgs.dev.azure.com/repstor/_packaging/WorkHub_Nuget/nuget/v3/index.json is unauthorized when Metalama runs.

The first Metalama compiles any project for a platform, we create an empty project under /Temp/Metalama/AssemblyLocator/ that downloads Roslyn for this platform through NuGet. We copy the NuGet sources from the source-code project to the /Temp/Metalama/AssemblyLocator/ project. However we assume that the source is already authorized.

Do you see a reason why it would not be authorized?

[gfraiteur]

Is your authentication configured in nuget.config using an API key or username/password? That would explain the failure.

[hazzinator1]

The feed is published on our Azure Dev Ops tenant and access is handled by Visual Studio's logged in account. The feed is locked down to people that have access to our tenant's Dev Ops. There's no username/password used anywhere.

The dev on our team said that to fix the "unauthenticated" error, he removed the Microsoft.CodeAnalysis.CSharp package from the WorkHub_Nuget source (no clue why it's in there...) and re-added it with the normal nuget.org one.

[prochan2]

We've analyzed your scenario and planned an improvement to avoid this issue. This improvement is planned for the next version of Metalama, which will be released along with .NET 9.

Did the issue disappear after removing the Microsoft.CodeAnalysis.CSharp package from the WorkHub_Nuget source? Isn't the reason it was there that you have nuget.org enabled as an upstream source for this feed?

[hazzinator1]

We've analyzed your scenario and planned an improvement to avoid this issue. This improvement is planned for the next version of Metalama, which will be released along with .NET 9.

Did the issue disappear after removing the Microsoft.CodeAnalysis.CSharp package from the WorkHub_Nuget source? Isn't the reason it was there that you have nuget.org enabled as an upstream source for this feed?

Appreciate the quick response! The issue did disappear after removing the Microsoft.CodeAnalysis.CSharp package, and no there's no upstream sources in our Nuget feed, it's just the two packages previously mentioned.

[gfraiteur]

We attempted to fix this issue but were not able to.

The workaround is to use another authentication mechanism, i.e. one that do not rely on NuGet running in the Visual Studio process.