Use framework-specific dependencies for .NET Framework versions #4505

iskiselev · 2025-10-07T03:28:35Z

Why

Currently OTEL registers in GAC assemblies, that was never intendend to be put in GAC on latest framework - and not registering netstandard.dll on 4.6.2. It results in issues discussed at #4186 (comment)

What

With this change, we pack different set of assemblies for supported .NET Frameworks:

4.6.2
4.7
4.7.1
4.7.2 and up

Only assemblies for current framework will be registered in GAC at install time or loaded from installation dir.
To minimize size set of assemblies deduplicated - with assemblies that used in all .NET Frameworks still stay at netfx folders. Assemblies used only in some versions stays in oldest TFM folder. For other TFM using same assembly .link file will be created that points to TFM with assembly.
To simplify buget packages tracking CentralPackageTransitivePinningEnabled for newly created OpenTelemetry.AutoInstrumentation.Assemblies.NetFramework.csproj was enabled - with it transient auto-generated packages were removed from OpenTelemetry.AutoInstrumentation.csproj.
.NET Framework version resolved through registry check in installation, profiler and managed code. It associated with some risk (proper rights). If version will not be resolved, it is fallback to 4.6.2, which should have same behaviour as before this change. It may be better nowdays to fallback to 4.7.2 - as most people probably have it.
Deployment for .Net Frameworks higher than 4.7.2 are same as for 4.7.2, so we do not build them - but test added to validate it.

Tests

validated OTEL works when assemblies are loaded from install folder on .NET 4.7.2.
validated that .link files are loaded correctly
validated that GAC installation works properly
validated that nuget installation was not affected

Checklist

CHANGELOG.md is updated.
Documentation is updated.
New features are covered by tests.

Open questions

Should we fallback to 4.7.2 instead of 4.6.2 if .Net Framework version not detected?
Decide if we need any replacement for deleted TransientDependenciesTests.DefinedTransientDeps_Are_MatchingGeneratedDeps. Do we need it once we start utilize CentralPackageTransitivePinningEnabled?
We don't have reference/version pinning in global/src level of Directory.Packages.props for some transitive packages.
Should we have it? Currently they are added as other transitive dependencies in OpenTelemetry.AutoInstrumentation.Assemblies.NetFramework/Directory.Packages.props. We can prevent it by restoring !dep.Name.StartsWith("OpenTelemetry") && dep.Name != "OpenTracing" in Generator, but pinning them through higher level Directory.Packages.props may be better idea. Packages to discuss:
- OpenTelemetry.Api.ProviderBuilderExtensions
- OpenTelemetry.Instrumentation.AspNet.TelemetryHttpModule
- OpenTracing
Should we integrate OpenTelemetry.AutoInstrumentation.Assemblies.NetFramework/Directory.Packages.props with dependabot? Priory only dependencies in top-level Directory.Packages.props were processed.
More automation tests? Suggest what to cover.

…uGet package. Removed TransientDependenciesTests - it should be rewritten later.

…ation.Assemblies.NetFramework It partially resolve open-telemetry#4520 by making both NuGet and zip version of OpenTelemetry.AutoInstrumentation reference same versions of dependencies, but not change assembly redirections or versions included in zip. Switched DependencyListGenerator to use dotnet list package internally. Validate defined PackageVersion through MsBuild evaluation.

build/Build.Steps.cs

RassK · 2025-10-22T16:08:08Z

build/Build.Steps.cs

    private string MapToFolderOutput(TargetFramework targetFramework)
    {
-        return targetFramework.ToString().StartsWith("net4") ? "netfx" : "net";
+        return targetFramework.ToString().StartsWith("net4") ? $"netfx" : "net";


Suggested change

return targetFramework.ToString().StartsWith("net4") ? $"netfx" : "net";

return targetFramework.ToString().StartsWith("net4") ? "netfx" : "net";

martincostello · 2025-10-23T10:12:25Z

build/TargetFramework.cs

    public static readonly TargetFramework NET462 = new() { Value = "net462" };
+    public static readonly TargetFramework NET47 = new() { Value = "net47" };
+    public static readonly TargetFramework NET471 = new() { Value = "net471" };
+    public static readonly TargetFramework NET472 = new() { Value = "net472" };


Do you need net48 and net481 too?

Currently we don't need net48 and net481, as all of our dependencies does not have difference between 4.7.2 and higher. I've added new NetFrameworkDistroTests.ReferencedPackagesNoUnsupportedTfm test that validates it. If any dependencies will do customizations for 4.8, 4.8.1 or potential newer .Net Framework - it will fail. There is comment in tests what should be done in that case.

src/OpenTelemetry.AutoInstrumentation.Native/cor_profiler.cpp

nrcventura · 2025-10-24T20:03:32Z

Should we fallback to 4.7.2 instead of 4.6.2 if .Net Framework version not detected?

As was described in the SIG meeting, I think falling back to 4.6.2 makes sense to maintain the existing the behavior. However, I'm wondering if we can improve upon it for those using the install script? Maybe the install script is run with enough permissions to configure an environment variable to modify the fallback behavior if a newer version of .net framework is detected at install time. If so, something like that could be implemented separately.

nrcventura · 2025-10-24T22:16:07Z

src/OpenTelemetry.AutoInstrumentation.Native/cor_profiler.cpp

+    int frameworkVersion = 462;
+
+    HKEY hKey   = nullptr;
+    LONG result = RegOpenKeyExW(HKEY_LOCAL_MACHINE, L"SOFTWARE\\Microsoft\\NET Framework Setup\\NDP\\v4\\Full\\", 0,


The registry check logic is in multiple locations. Is it possible to just have it checked in one place and made available in both locations?

nrcventura · 2025-10-24T22:49:33Z

More automation tests? Suggest what to cover.

One idea for a set of integration tests is having a test app that runs in windows containers with only a specific .net framework version available to make it easier to validate behavior for each specific .net framework version. I don't know what type of test app we need to have to ensure that the correct dependencies are in place. I also don't know if these tests will have enough value given how long it can take to download and run these containers.

iskiselev · 2025-10-28T03:19:51Z

Should we fallback to 4.7.2 instead of 4.6.2 if .Net Framework version not detected?

As was described in the SIG meeting, I think falling back to 4.6.2 makes sense to maintain the existing the behavior. However, I'm wondering if we can improve upon it for those using the install script? Maybe the install script is run with enough permissions to configure an environment variable to modify the fallback behavior if a newer version of .net framework is detected at install time. If so, something like that could be implemented separately.

@nrcventura, I will do .Net Framework 4.7.2 detection based on presence of ICorProfilerInfo8. We will fall back to registry check only for 4.6.2, 4.7, 4.7.1. If we ever need support different packing for 4.8 or newer, we will need to reconsider it. On other hand, by that time we probably would not need anything older than 4.7.2 - as 4.6.2 - 4.7.1 probably will be out of support after Jan 12, 2027.
I will also use PInvoke into profiler code to not duplicate registry query.

iskiselev · 2025-10-28T03:29:35Z

One idea for a set of integration tests is having a test app that runs in windows containers with only a specific .net framework version available to make it easier to validate behavior for each specific .net framework version. I don't know what type of test app we need to have to ensure that the correct dependencies are in place. I also don't know if these tests will have enough value given how long it can take to download and run these containers.

@nrcventura, it may be hard to do it. To test older frameworks, docker should be based on Windows Server 2016 (as Windows Server 2019 has 4.7.2 pre-installed). As I understand (I'm not sure about it), windows docker in Github CI should match host version - and looks like there is no Windows Server 2016 runner. I also have concerns about value of this tests and whether their development is proper time investment, with limited lifespan of frameworks older than 4.7.2 (both .Net Framework 4.6.2 and Windows Server 2016 extended support will be finished on January 12, 2027)

Use ICorProfilerInfo8 for .NET Framework 4.7.2 detection. Use PInvoke for framework resolution in loader. AssemblyResolver make non-static to allow usage of log in ctor.

Kielek · 2025-10-28T09:27:21Z

Note

When merged, close also #3817

Kielek · 2025-10-28T08:22:26Z

CHANGELOG.md

 - .NET Framework only, following packages updated
  - `OpenTelemetry.Instrumentation.AspNet` from `1.12.0-beta.1` to `1.13.0-beta.2`.

+#### Dependencies on .Net Framework


Suggested change

#### Dependencies on .Net Framework

#### Dependencies on .NET Framework

Kielek · 2025-10-28T08:22:44Z

CHANGELOG.md

+#### Dependencies on .Net Framework
+
+When OpenTelemetry .NET AutoInstrumentation is compiled for .NET Framework,
+it uses the net462 Target Framework Moniker (TFM). As a result, the ZIP archive


Suggested change

it uses the net462 Target Framework Moniker (TFM). As a result, the ZIP archive

it uses the `net462` Target Framework Moniker (TFM). As a result, the ZIP archive

Kielek · 2025-10-28T09:18:26Z

tools/DependencyListGenerator/DotNetOutdated/Services/DotNetPackageListService.cs

+        string[] arguments = new[]
+        {
+            "list", $"\"{projectPath}\"", "package", "--include-transitive", "--format", "json", "--output-version",
+            "1"
+        };


Suggested change

string[] arguments = new[]

{

"list", $"\"{projectPath}\"", "package", "--include-transitive", "--format", "json", "--output-version",

"1"

};

string[] arguments =

[

"list", $"\"{projectPath}\"", "package", "--include-transitive", "--format", "json", "--output-version", "1"

];

Kielek · 2025-10-28T09:25:27Z

tools/DependencyListGenerator/DotNetOutdated/Models/PackageListModel.cs

+
+using System.Text.Json.Serialization;
+
+public record PackageListModel


.NET provides some wrappers to play with nugets, and other stuff.
Eg https://www.nuget.org/packages/NuGet.ProjectModel

Is there any chance that there is similar package for this case?

Kielek · 2025-10-28T09:29:22Z

test/IntegrationTests/BuildTests.DistributionStructure_windows.verified.txt

Could you please share the new/old package sizes on Windows?

Kielek · 2025-10-28T09:31:10Z

test/IntegrationTests/BuildTests.DistributionStructure_windows.verified.txt

+  \netfx\net471\System.Security.SecureString.dll,
+  \netfx\net471\System.Threading.Overlapped.dll,
+  \netfx\net471\System.Xml.XPath.XDocument.dll,
+  \netfx\net472\_._,


This look strange. What that means?

Kielek · 2025-10-28T09:46:44Z

src/OpenTelemetry.AutoInstrumentation.Native/cor_profiler.cpp

+                // Map release numbers to framework versions
+                // Based on Microsoft documentation:
+                // https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed
+                if (releaseValue >= 461308)


I would put here all framework versions, up to 4.8.1.
in if statement, we can put something like

// intentionally pinining to .NET Framework 4.7.2, there is no differences in the expected library set frameworkVersion = 472;

or similiar.

Now, we understand that it was intentional, in the future we can avoid some archeological stuff.

Kielek · 2025-10-28T09:50:40Z

script-templates/OpenTelemetry.DotNet.Auto.psm1.template

+
+    $release = Get-ItemPropertyValue -LiteralPath 'HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' -Name Release
+    switch ($release) {
+        { $_ -ge 461808 } { $fxversion = 'net472'; break }


I would put all versions also here, similar comment as in cor_profiler.cpp

Kielek · 2025-10-28T09:50:52Z

docs/README.md

 Uninstall-OpenTelemetryCore
 ```

+#### Update .Net Framework version


Suggested change

#### Update .Net Framework version

#### Update .NET Framework version

Kielek · 2025-10-28T10:02:48Z

Should we fallback to 4.7.2 instead of 4.6.2 if .Net Framework version not detected?

Do you know what can be the most common case when this can happen? Do you see any other possibility to check what .NET Framework is executed?

Decide if we need any replacement for deleted TransientDependenciesTests.DefinedTransientDeps_Are_MatchingGeneratedDeps. Do we need it once we start utilize CentralPackageTransitivePinningEnabled?

Historically, it prevented me at least once to merge wrong PR. If you see possibility to still have it (this is pretty new feature in .NET) it will be great. I think, it can be done in separate PR, if you can commit to finish it;

We don't have reference/version pinning in global/src level of Directory.Packages.props for some transitive packages.
Should we have it? Currently they are added as other transitive dependencies in OpenTelemetry.AutoInstrumentation.Assemblies.NetFramework/Directory.Packages.props. We can prevent it by restoring !dep.Name.StartsWith("OpenTelemetry") && dep.Name != "OpenTracing" in Generator, but pinning them through higher level Directory.Packages.props may be better idea. Packages to discuss:

OpenTelemetry.Api.ProviderBuilderExtensions

OpenTelemetry.Instrumentation.AspNet.TelemetryHttpModule

OpenTracing

OpenTelemetry.Api.ProviderBuilderExtensions always has the same version as OpenTelemetry.Api/OpenTelemetry
OpenTelemetry.Instrumentation.AspNet.TelemetryHttpModule is always released together with OpenTelemetry.Instrumentation.AspNet. Both of them are versioned together
OpenTracing is a dead package. I do not expect new release here

I do not have strong opinion here.

Should we integrate OpenTelemetry.AutoInstrumentation.Assemblies.NetFramework/Directory.Packages.props with dependabot? Priory only dependencies in top-level Directory.Packages.props were processed.

I would say, that we should switch whole repository to renovate first, then make any additional inclusions.
Based on what I see, renovate is much more reliable than dependabot.

Use framework-specific dependency collection for .Net Framework versions

f5da22d

iskiselev requested a review from a team as a code owner October 7, 2025 03:28

iskiselev marked this pull request as draft October 7, 2025 03:28

iskiselev added 17 commits October 7, 2025 11:07

Merge remote-tracking branch 'origin/main'

0f69e49

Format fix

0045c40

Excluded Assemblies.NetFramework from build on non-windows OS

8b4d03b

Publish .Net Framework project only on windows

c347876

Fixed format for c# files

8b05f5f

Excluded .NetFramework assemblies-collecting project from producing N…

4ef8534

…uGet package. Removed TransientDependenciesTests - it should be rewritten later.

Fixed test

ba8784d

Bootstrap test fix (explicit reference)

db32846

Test fix (explicit reference)

ce49362

Verified file structure fixed

3c38ccc

Integration test fix (explicit reference)

98f034d

Preserve empty folders with "_._" file

fad337e

Include _._ in verified structure.

96cfbec

Fixed assembly redirection table generation / selection

3b2b3fe

Format fix

0829341

Corrected build/test machine GAC install/uninstall

200839e

Fixed empty lines

69075e0

iskiselev mentioned this pull request Oct 14, 2025

Binaries different in different distributions #4520

Open

iskiselev added 7 commits October 15, 2025 10:35

Merge remote-tracking branch 'origin/main'

0d8480c

Updated dependencies

589f02a

Reverted version override for test application

f9295d5

Removed unused code

7879ade

Updated image pinning to run tests

fcd3cfb

Merge remote-tracking branch 'origin/main'

24957a5

iskiselev changed the title ~~WIP Use framework-specific dependencies for .Net Framework versions~~ Use framework-specific dependencies for .Net Framework versions Oct 16, 2025

README modified and tests added

44d1c3c

Changelog updated. Fixed BOM.

d4938a6

iskiselev marked this pull request as ready for review October 16, 2025 23:24

iskiselev added 7 commits October 16, 2025 16:27

Changelog fixed

e8330c6

Generated files updates

22524fb

Changelog fixed

7ba8086

Generated file update

6cea088

Test with latest .NET SDK

57b2d19

Test with latest .NET SDK

634d4cc

Merge remote-tracking branch 'origin/main' into multitargeting-fx

19d1000

RassK reviewed Oct 22, 2025

View reviewed changes

build/Build.Steps.cs Show resolved Hide resolved

RassK reviewed Oct 22, 2025

View reviewed changes

martincostello reviewed Oct 23, 2025

View reviewed changes

nrcventura reviewed Oct 24, 2025

View reviewed changes

iskiselev added 2 commits October 28, 2025 00:46

PR feedback implemented

8a1f1f2

Use ICorProfilerInfo8 for .NET Framework 4.7.2 detection. Use PInvoke for framework resolution in loader. AssemblyResolver make non-static to allow usage of log in ctor.

Merge remote-tracking branch 'origin/main' into multitargeting-fx

afef7dd

Kielek changed the title ~~Use framework-specific dependencies for .Net Framework versions~~ Use framework-specific dependencies for .NET Framework versions Oct 28, 2025

Kielek reviewed Oct 28, 2025

View reviewed changes

	return targetFramework.ToString().StartsWith("net4") ? $"netfx" : "net";
	return targetFramework.ToString().StartsWith("net4") ? "netfx" : "net";

	#### Dependencies on .Net Framework
	#### Dependencies on .NET Framework

	it uses the net462 Target Framework Moniker (TFM). As a result, the ZIP archive
	it uses the `net462` Target Framework Moniker (TFM). As a result, the ZIP archive


		using System.Text.Json.Serialization;

		public record PackageListModel

	#### Update .Net Framework version
	#### Update .NET Framework version

Uh oh!

Use framework-specific dependencies for .NET Framework versions #4505

Are you sure you want to change the base?

Use framework-specific dependencies for .NET Framework versions #4505

Uh oh!

Conversation

iskiselev commented Oct 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why

What

Tests

Checklist

Open questions

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

nrcventura commented Oct 24, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nrcventura commented Oct 24, 2025

Uh oh!

iskiselev commented Oct 28, 2025

Uh oh!

iskiselev commented Oct 28, 2025

Uh oh!

Kielek commented Oct 28, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kielek commented Oct 28, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

iskiselev commented Oct 7, 2025 •

edited

Loading