Disable TargetingPack Analyzers

[ericstj]

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

Author:	ericstj
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[ericstj]

I'll need to reduce the condition down to just the latest framework.

[ericstj]

This might not actually fix the problem. @tarekgh noticed that he still sees a failure with this change. That's due to the failure happening when loading the net8.0 generator.

For some reason the net8.0 generator is binding to the live built version of Microsoft.Interop.SourceGeneration. This could be happening if we're passing the live-built generator bits to downlevel projects. I remember the interop generator does this to add support for interop generation to downlevel frameworks. @jkoritzinsky@elinor-fung

[ViktorHofer]

Doesn't this change partially undo 07ae197 which was observed as general goodness?

Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

Shouldn't this infrastructure prevent that?

[ViktorHofer]

When I read this, it wasn't obvious to me that the target only applies to projects that don't use the local targeting / runtime pack. You want to point that out in the code comment.

For which projects should this target run? Microsoft.NETCore.Platforms doesn't use the local targeting pack but doesn't disable implicit framework references. Are there other such projects under src/libraries?

[ericstj]

Here's the reason this was failing:

/analyzer:C:\oss\runtime\artifacts\bin\Microsoft.Interop.SourceGeneration\Release\netstandard2.0\Microsoft.Interop.SourceGeneration.dll
/analyzer:C:\oss\runtime\artifacts\bin\LibraryImportGenerator\Release\netstandard2.0\Microsoft.Interop.LibraryImportGenerator.dll
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.ComInterfaceGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.JavaScript.JSImportGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

So during the runtime build, we include 8.0 analyzers from the ref pack, but the live built LibraryImportGenerator and Microsoft.Interop.SourceGeneration.dll. Roslyn will force all generators to use that live built Microsoft.Interop.SourceGeneration.dll - even the 8.0 ones. Tarek might be hitting this because he has an RC2 SDK installed, others may hit this as soon as they have RC2. RC2 may be observing this due to a dependency on the removed type - though I haven't found that just yet.

[jkoritzinsky]

The area you're looking for is in generators.targets. However, I wonder if this is the correct fix. The generators that are included in the ref pack are designed for that particular TFM and they generally aren't designed to work downlevel. LibraryImportGenerator is the exception here, though that support is limited. It might be better to change generators.targets to not include the references to LibraryImportGenerator and Microsoft.Interop.SourceGeneration for downlevel netX.0 TFMs (we still need it for netstandard2.0).

[ViktorHofer]

/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

I believe a better fix would be to make sure that when that shared live built source generator is used (Microsoft.Interop.SourceGeneration.dll), the dependent live built source generator are also referenced so that there isn't a mix.

[ericstj]

@jkoritzinsky can you take a crack at fixing this in the way that makes the most sense for the interop source generators?

My initial goal here was to minimize the use of those LKG generators when they'd be in torn state. Given we have very few projects targeting LKG for the latest .NET it seemed removing the generators for those would fix it - but I had missed the downlevel cases which seem to be more important.

[jkoritzinsky]

I'll take a look!

[ericstj]

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

Agreed for net8.0 - I wasn't proposing we drop source generators from older frameworks. For latest we should really opt for using the code we are building rather than some past snapshot of the SDK. Not doing so might lead us to miss bugs or run in unusual torn state situations.

[ericstj]

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

Author:	ericstj
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[ericstj]

I'll need to reduce the condition down to just the latest framework.

[ericstj]

This might not actually fix the problem. @tarekgh noticed that he still sees a failure with this change. That's due to the failure happening when loading the net8.0 generator.

For some reason the net8.0 generator is binding to the live built version of Microsoft.Interop.SourceGeneration. This could be happening if we're passing the live-built generator bits to downlevel projects. I remember the interop generator does this to add support for interop generation to downlevel frameworks. @jkoritzinsky@elinor-fung

[ViktorHofer]

Doesn't this change partially undo 07ae197 which was observed as general goodness?

Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

Shouldn't this infrastructure prevent that?

[ViktorHofer]

When I read this, it wasn't obvious to me that the target only applies to projects that don't use the local targeting / runtime pack. You want to point that out in the code comment.

For which projects should this target run? Microsoft.NETCore.Platforms doesn't use the local targeting pack but doesn't disable implicit framework references. Are there other such projects under src/libraries?

[ericstj]

Here's the reason this was failing:

/analyzer:C:\oss\runtime\artifacts\bin\Microsoft.Interop.SourceGeneration\Release\netstandard2.0\Microsoft.Interop.SourceGeneration.dll
/analyzer:C:\oss\runtime\artifacts\bin\LibraryImportGenerator\Release\netstandard2.0\Microsoft.Interop.LibraryImportGenerator.dll
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.ComInterfaceGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.JavaScript.JSImportGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

So during the runtime build, we include 8.0 analyzers from the ref pack, but the live built LibraryImportGenerator and Microsoft.Interop.SourceGeneration.dll. Roslyn will force all generators to use that live built Microsoft.Interop.SourceGeneration.dll - even the 8.0 ones. Tarek might be hitting this because he has an RC2 SDK installed, others may hit this as soon as they have RC2. RC2 may be observing this due to a dependency on the removed type - though I haven't found that just yet.

[jkoritzinsky]

The area you're looking for is in generators.targets. However, I wonder if this is the correct fix. The generators that are included in the ref pack are designed for that particular TFM and they generally aren't designed to work downlevel. LibraryImportGenerator is the exception here, though that support is limited. It might be better to change generators.targets to not include the references to LibraryImportGenerator and Microsoft.Interop.SourceGeneration for downlevel netX.0 TFMs (we still need it for netstandard2.0).

[ViktorHofer]

/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

I believe a better fix would be to make sure that when that shared live built source generator is used (Microsoft.Interop.SourceGeneration.dll), the dependent live built source generator are also referenced so that there isn't a mix.

[ericstj]

@jkoritzinsky can you take a crack at fixing this in the way that makes the most sense for the interop source generators?

My initial goal here was to minimize the use of those LKG generators when they'd be in torn state. Given we have very few projects targeting LKG for the latest .NET it seemed removing the generators for those would fix it - but I had missed the downlevel cases which seem to be more important.

[jkoritzinsky]

I'll take a look!

[ericstj]

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

Agreed for net8.0 - I wasn't proposing we drop source generators from older frameworks. For latest we should really opt for using the code we are building rather than some past snapshot of the SDK. Not doing so might lead us to miss bugs or run in unusual torn state situations.

[ericstj]

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

Author:	ericstj
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[ericstj]

I'll need to reduce the condition down to just the latest framework.

[ericstj]

This might not actually fix the problem. @tarekgh noticed that he still sees a failure with this change. That's due to the failure happening when loading the net8.0 generator.

For some reason the net8.0 generator is binding to the live built version of Microsoft.Interop.SourceGeneration. This could be happening if we're passing the live-built generator bits to downlevel projects. I remember the interop generator does this to add support for interop generation to downlevel frameworks. @jkoritzinsky@elinor-fung

[ViktorHofer]

Doesn't this change partially undo 07ae197 which was observed as general goodness?

Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

Shouldn't this infrastructure prevent that?

[ViktorHofer]

When I read this, it wasn't obvious to me that the target only applies to projects that don't use the local targeting / runtime pack. You want to point that out in the code comment.

For which projects should this target run? Microsoft.NETCore.Platforms doesn't use the local targeting pack but doesn't disable implicit framework references. Are there other such projects under src/libraries?

[ericstj]

Here's the reason this was failing:

/analyzer:C:\oss\runtime\artifacts\bin\Microsoft.Interop.SourceGeneration\Release\netstandard2.0\Microsoft.Interop.SourceGeneration.dll
/analyzer:C:\oss\runtime\artifacts\bin\LibraryImportGenerator\Release\netstandard2.0\Microsoft.Interop.LibraryImportGenerator.dll
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.ComInterfaceGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.JavaScript.JSImportGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

So during the runtime build, we include 8.0 analyzers from the ref pack, but the live built LibraryImportGenerator and Microsoft.Interop.SourceGeneration.dll. Roslyn will force all generators to use that live built Microsoft.Interop.SourceGeneration.dll - even the 8.0 ones. Tarek might be hitting this because he has an RC2 SDK installed, others may hit this as soon as they have RC2. RC2 may be observing this due to a dependency on the removed type - though I haven't found that just yet.

[jkoritzinsky]

The area you're looking for is in generators.targets. However, I wonder if this is the correct fix. The generators that are included in the ref pack are designed for that particular TFM and they generally aren't designed to work downlevel. LibraryImportGenerator is the exception here, though that support is limited. It might be better to change generators.targets to not include the references to LibraryImportGenerator and Microsoft.Interop.SourceGeneration for downlevel netX.0 TFMs (we still need it for netstandard2.0).

[ViktorHofer]

/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

I believe a better fix would be to make sure that when that shared live built source generator is used (Microsoft.Interop.SourceGeneration.dll), the dependent live built source generator are also referenced so that there isn't a mix.

[ericstj]

@jkoritzinsky can you take a crack at fixing this in the way that makes the most sense for the interop source generators?

My initial goal here was to minimize the use of those LKG generators when they'd be in torn state. Given we have very few projects targeting LKG for the latest .NET it seemed removing the generators for those would fix it - but I had missed the downlevel cases which seem to be more important.

[jkoritzinsky]

I'll take a look!

[ericstj]

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

Agreed for net8.0 - I wasn't proposing we drop source generators from older frameworks. For latest we should really opt for using the code we are building rather than some past snapshot of the SDK. Not doing so might lead us to miss bugs or run in unusual torn state situations.

[ericstj]

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

Author:	ericstj
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[ericstj]

I'll need to reduce the condition down to just the latest framework.

[ericstj]

This might not actually fix the problem. @tarekgh noticed that he still sees a failure with this change. That's due to the failure happening when loading the net8.0 generator.

For some reason the net8.0 generator is binding to the live built version of Microsoft.Interop.SourceGeneration. This could be happening if we're passing the live-built generator bits to downlevel projects. I remember the interop generator does this to add support for interop generation to downlevel frameworks. @jkoritzinsky@elinor-fung

[ViktorHofer]

Doesn't this change partially undo 07ae197 which was observed as general goodness?

Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

Shouldn't this infrastructure prevent that?

[ViktorHofer]

When I read this, it wasn't obvious to me that the target only applies to projects that don't use the local targeting / runtime pack. You want to point that out in the code comment.

For which projects should this target run? Microsoft.NETCore.Platforms doesn't use the local targeting pack but doesn't disable implicit framework references. Are there other such projects under src/libraries?

[ericstj]

Here's the reason this was failing:

/analyzer:C:\oss\runtime\artifacts\bin\Microsoft.Interop.SourceGeneration\Release\netstandard2.0\Microsoft.Interop.SourceGeneration.dll
/analyzer:C:\oss\runtime\artifacts\bin\LibraryImportGenerator\Release\netstandard2.0\Microsoft.Interop.LibraryImportGenerator.dll
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.ComInterfaceGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.JavaScript.JSImportGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

So during the runtime build, we include 8.0 analyzers from the ref pack, but the live built LibraryImportGenerator and Microsoft.Interop.SourceGeneration.dll. Roslyn will force all generators to use that live built Microsoft.Interop.SourceGeneration.dll - even the 8.0 ones. Tarek might be hitting this because he has an RC2 SDK installed, others may hit this as soon as they have RC2. RC2 may be observing this due to a dependency on the removed type - though I haven't found that just yet.

[jkoritzinsky]

The area you're looking for is in generators.targets. However, I wonder if this is the correct fix. The generators that are included in the ref pack are designed for that particular TFM and they generally aren't designed to work downlevel. LibraryImportGenerator is the exception here, though that support is limited. It might be better to change generators.targets to not include the references to LibraryImportGenerator and Microsoft.Interop.SourceGeneration for downlevel netX.0 TFMs (we still need it for netstandard2.0).

[ViktorHofer]

/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

I believe a better fix would be to make sure that when that shared live built source generator is used (Microsoft.Interop.SourceGeneration.dll), the dependent live built source generator are also referenced so that there isn't a mix.

[ericstj]

@jkoritzinsky can you take a crack at fixing this in the way that makes the most sense for the interop source generators?

My initial goal here was to minimize the use of those LKG generators when they'd be in torn state. Given we have very few projects targeting LKG for the latest .NET it seemed removing the generators for those would fix it - but I had missed the downlevel cases which seem to be more important.

[jkoritzinsky]

I'll take a look!

[ericstj]

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

Agreed for net8.0 - I wasn't proposing we drop source generators from older frameworks. For latest we should really opt for using the code we are building rather than some past snapshot of the SDK. Not doing so might lead us to miss bugs or run in unusual torn state situations.

[ericstj]

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

Author:	ericstj
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[ericstj]

I'll need to reduce the condition down to just the latest framework.

[ericstj]

This might not actually fix the problem. @tarekgh noticed that he still sees a failure with this change. That's due to the failure happening when loading the net8.0 generator.

For some reason the net8.0 generator is binding to the live built version of Microsoft.Interop.SourceGeneration. This could be happening if we're passing the live-built generator bits to downlevel projects. I remember the interop generator does this to add support for interop generation to downlevel frameworks. @jkoritzinsky@elinor-fung

[ViktorHofer]

Doesn't this change partially undo 07ae197 which was observed as general goodness?

Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

Shouldn't this infrastructure prevent that?

[ViktorHofer]

When I read this, it wasn't obvious to me that the target only applies to projects that don't use the local targeting / runtime pack. You want to point that out in the code comment.

For which projects should this target run? Microsoft.NETCore.Platforms doesn't use the local targeting pack but doesn't disable implicit framework references. Are there other such projects under src/libraries?

[ericstj]

Here's the reason this was failing:

/analyzer:C:\oss\runtime\artifacts\bin\Microsoft.Interop.SourceGeneration\Release\netstandard2.0\Microsoft.Interop.SourceGeneration.dll
/analyzer:C:\oss\runtime\artifacts\bin\LibraryImportGenerator\Release\netstandard2.0\Microsoft.Interop.LibraryImportGenerator.dll
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.ComInterfaceGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.JavaScript.JSImportGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

So during the runtime build, we include 8.0 analyzers from the ref pack, but the live built LibraryImportGenerator and Microsoft.Interop.SourceGeneration.dll. Roslyn will force all generators to use that live built Microsoft.Interop.SourceGeneration.dll - even the 8.0 ones. Tarek might be hitting this because he has an RC2 SDK installed, others may hit this as soon as they have RC2. RC2 may be observing this due to a dependency on the removed type - though I haven't found that just yet.

[jkoritzinsky]

The area you're looking for is in generators.targets. However, I wonder if this is the correct fix. The generators that are included in the ref pack are designed for that particular TFM and they generally aren't designed to work downlevel. LibraryImportGenerator is the exception here, though that support is limited. It might be better to change generators.targets to not include the references to LibraryImportGenerator and Microsoft.Interop.SourceGeneration for downlevel netX.0 TFMs (we still need it for netstandard2.0).

[ViktorHofer]

/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

I believe a better fix would be to make sure that when that shared live built source generator is used (Microsoft.Interop.SourceGeneration.dll), the dependent live built source generator are also referenced so that there isn't a mix.

[ericstj]

@jkoritzinsky can you take a crack at fixing this in the way that makes the most sense for the interop source generators?

My initial goal here was to minimize the use of those LKG generators when they'd be in torn state. Given we have very few projects targeting LKG for the latest .NET it seemed removing the generators for those would fix it - but I had missed the downlevel cases which seem to be more important.

[jkoritzinsky]

I'll take a look!

[ericstj]

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

Agreed for net8.0 - I wasn't proposing we drop source generators from older frameworks. For latest we should really opt for using the code we are building rather than some past snapshot of the SDK. Not doing so might lead us to miss bugs or run in unusual torn state situations.

[ericstj]

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

Author:	ericstj
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[ericstj]

I'll need to reduce the condition down to just the latest framework.

[ericstj]

This might not actually fix the problem. @tarekgh noticed that he still sees a failure with this change. That's due to the failure happening when loading the net8.0 generator.

For some reason the net8.0 generator is binding to the live built version of Microsoft.Interop.SourceGeneration. This could be happening if we're passing the live-built generator bits to downlevel projects. I remember the interop generator does this to add support for interop generation to downlevel frameworks. @jkoritzinsky@elinor-fung

[ViktorHofer]

Doesn't this change partially undo 07ae197 which was observed as general goodness?

Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

Shouldn't this infrastructure prevent that?

[ViktorHofer]

When I read this, it wasn't obvious to me that the target only applies to projects that don't use the local targeting / runtime pack. You want to point that out in the code comment.

For which projects should this target run? Microsoft.NETCore.Platforms doesn't use the local targeting pack but doesn't disable implicit framework references. Are there other such projects under src/libraries?

[ericstj]

Here's the reason this was failing:

/analyzer:C:\oss\runtime\artifacts\bin\Microsoft.Interop.SourceGeneration\Release\netstandard2.0\Microsoft.Interop.SourceGeneration.dll
/analyzer:C:\oss\runtime\artifacts\bin\LibraryImportGenerator\Release\netstandard2.0\Microsoft.Interop.LibraryImportGenerator.dll
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.ComInterfaceGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.JavaScript.JSImportGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

So during the runtime build, we include 8.0 analyzers from the ref pack, but the live built LibraryImportGenerator and Microsoft.Interop.SourceGeneration.dll. Roslyn will force all generators to use that live built Microsoft.Interop.SourceGeneration.dll - even the 8.0 ones. Tarek might be hitting this because he has an RC2 SDK installed, others may hit this as soon as they have RC2. RC2 may be observing this due to a dependency on the removed type - though I haven't found that just yet.

[jkoritzinsky]

The area you're looking for is in generators.targets. However, I wonder if this is the correct fix. The generators that are included in the ref pack are designed for that particular TFM and they generally aren't designed to work downlevel. LibraryImportGenerator is the exception here, though that support is limited. It might be better to change generators.targets to not include the references to LibraryImportGenerator and Microsoft.Interop.SourceGeneration for downlevel netX.0 TFMs (we still need it for netstandard2.0).

[ViktorHofer]

/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

I believe a better fix would be to make sure that when that shared live built source generator is used (Microsoft.Interop.SourceGeneration.dll), the dependent live built source generator are also referenced so that there isn't a mix.

[ericstj]

@jkoritzinsky can you take a crack at fixing this in the way that makes the most sense for the interop source generators?

My initial goal here was to minimize the use of those LKG generators when they'd be in torn state. Given we have very few projects targeting LKG for the latest .NET it seemed removing the generators for those would fix it - but I had missed the downlevel cases which seem to be more important.

[jkoritzinsky]

I'll take a look!

[ericstj]

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

Agreed for net8.0 - I wasn't proposing we drop source generators from older frameworks. For latest we should really opt for using the code we are building rather than some past snapshot of the SDK. Not doing so might lead us to miss bugs or run in unusual torn state situations.

[ericstj]

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

Author:	ericstj
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[ericstj]

I'll need to reduce the condition down to just the latest framework.

[ericstj]

This might not actually fix the problem. @tarekgh noticed that he still sees a failure with this change. That's due to the failure happening when loading the net8.0 generator.

For some reason the net8.0 generator is binding to the live built version of Microsoft.Interop.SourceGeneration. This could be happening if we're passing the live-built generator bits to downlevel projects. I remember the interop generator does this to add support for interop generation to downlevel frameworks. @jkoritzinsky@elinor-fung

[ViktorHofer]

Doesn't this change partially undo 07ae197 which was observed as general goodness?

Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

Shouldn't this infrastructure prevent that?

[ViktorHofer]

When I read this, it wasn't obvious to me that the target only applies to projects that don't use the local targeting / runtime pack. You want to point that out in the code comment.

For which projects should this target run? Microsoft.NETCore.Platforms doesn't use the local targeting pack but doesn't disable implicit framework references. Are there other such projects under src/libraries?

[ericstj]

Here's the reason this was failing:

/analyzer:C:\oss\runtime\artifacts\bin\Microsoft.Interop.SourceGeneration\Release\netstandard2.0\Microsoft.Interop.SourceGeneration.dll
/analyzer:C:\oss\runtime\artifacts\bin\LibraryImportGenerator\Release\netstandard2.0\Microsoft.Interop.LibraryImportGenerator.dll
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.ComInterfaceGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.JavaScript.JSImportGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

So during the runtime build, we include 8.0 analyzers from the ref pack, but the live built LibraryImportGenerator and Microsoft.Interop.SourceGeneration.dll. Roslyn will force all generators to use that live built Microsoft.Interop.SourceGeneration.dll - even the 8.0 ones. Tarek might be hitting this because he has an RC2 SDK installed, others may hit this as soon as they have RC2. RC2 may be observing this due to a dependency on the removed type - though I haven't found that just yet.

[jkoritzinsky]

The area you're looking for is in generators.targets. However, I wonder if this is the correct fix. The generators that are included in the ref pack are designed for that particular TFM and they generally aren't designed to work downlevel. LibraryImportGenerator is the exception here, though that support is limited. It might be better to change generators.targets to not include the references to LibraryImportGenerator and Microsoft.Interop.SourceGeneration for downlevel netX.0 TFMs (we still need it for netstandard2.0).

[ViktorHofer]

/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

I believe a better fix would be to make sure that when that shared live built source generator is used (Microsoft.Interop.SourceGeneration.dll), the dependent live built source generator are also referenced so that there isn't a mix.

[ericstj]

@jkoritzinsky can you take a crack at fixing this in the way that makes the most sense for the interop source generators?

My initial goal here was to minimize the use of those LKG generators when they'd be in torn state. Given we have very few projects targeting LKG for the latest .NET it seemed removing the generators for those would fix it - but I had missed the downlevel cases which seem to be more important.

[jkoritzinsky]

I'll take a look!

[ericstj]

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

Agreed for net8.0 - I wasn't proposing we drop source generators from older frameworks. For latest we should really opt for using the code we are building rather than some past snapshot of the SDK. Not doing so might lead us to miss bugs or run in unusual torn state situations.

[ericstj]

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fix issue introduced in #92301

This makes it the default to remove all analyzers that come from the TargetingPack unless specified.

This is important so that we don't mix the LKG binaries in the same process that will later load the live-built binaries. Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

I considered making this opt-in instead of opt-out, but I don't think we want anything in the repo loading the LKG binaries in the compiler process.

Author:	ericstj
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[ericstj]

I'll need to reduce the condition down to just the latest framework.

[ericstj]

This might not actually fix the problem. @tarekgh noticed that he still sees a failure with this change. That's due to the failure happening when loading the net8.0 generator.

For some reason the net8.0 generator is binding to the live built version of Microsoft.Interop.SourceGeneration. This could be happening if we're passing the live-built generator bits to downlevel projects. I remember the interop generator does this to add support for interop generation to downlevel frameworks. @jkoritzinsky@elinor-fung

[ViktorHofer]

Doesn't this change partially undo 07ae197 which was observed as general goodness?

Doing so can result in the live built binaries being ignored since they have the same assembly name as those already loaded in process.

Shouldn't this infrastructure prevent that?

[ViktorHofer]

When I read this, it wasn't obvious to me that the target only applies to projects that don't use the local targeting / runtime pack. You want to point that out in the code comment.

For which projects should this target run? Microsoft.NETCore.Platforms doesn't use the local targeting pack but doesn't disable implicit framework references. Are there other such projects under src/libraries?

[ericstj]

Here's the reason this was failing:

/analyzer:C:\oss\runtime\artifacts\bin\Microsoft.Interop.SourceGeneration\Release\netstandard2.0\Microsoft.Interop.SourceGeneration.dll
/analyzer:C:\oss\runtime\artifacts\bin\LibraryImportGenerator\Release\netstandard2.0\Microsoft.Interop.LibraryImportGenerator.dll
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.ComInterfaceGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/Microsoft.Interop.JavaScript.JSImportGenerator.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

So during the runtime build, we include 8.0 analyzers from the ref pack, but the live built LibraryImportGenerator and Microsoft.Interop.SourceGeneration.dll. Roslyn will force all generators to use that live built Microsoft.Interop.SourceGeneration.dll - even the 8.0 ones. Tarek might be hitting this because he has an RC2 SDK installed, others may hit this as soon as they have RC2. RC2 may be observing this due to a dependency on the removed type - though I haven't found that just yet.

[jkoritzinsky]

The area you're looking for is in generators.targets. However, I wonder if this is the correct fix. The generators that are included in the ref pack are designed for that particular TFM and they generally aren't designed to work downlevel. LibraryImportGenerator is the exception here, though that support is limited. It might be better to change generators.targets to not include the references to LibraryImportGenerator and Microsoft.Interop.SourceGeneration for downlevel netX.0 TFMs (we still need it for netstandard2.0).

[ViktorHofer]

/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll"
/analyzer:"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.0-rc.2.23469.9\analyzers/dotnet/cs/System.Text.RegularExpressions.Generator.dll"

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

I believe a better fix would be to make sure that when that shared live built source generator is used (Microsoft.Interop.SourceGeneration.dll), the dependent live built source generator are also referenced so that there isn't a mix.

[ericstj]

@jkoritzinsky can you take a crack at fixing this in the way that makes the most sense for the interop source generators?

My initial goal here was to minimize the use of those LKG generators when they'd be in torn state. Given we have very few projects targeting LKG for the latest .NET it seemed removing the generators for those would fix it - but I had missed the downlevel cases which seem to be more important.

[jkoritzinsky]

I'll take a look!

[ericstj]

These two don't depend on that shared source generator and should still be consumed from the targeting pack.

Agreed for net8.0 - I wasn't proposing we drop source generators from older frameworks. For latest we should really opt for using the code we are building rather than some past snapshot of the SDK. Not doing so might lead us to miss bugs or run in unusual torn state situations.