-
Notifications
You must be signed in to change notification settings - Fork 123
Use framework-specific dependencies for .Net Framework versions #4505
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…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.
| private static readonly IEnumerable<TargetFramework> TargetFrameworks = new[] | ||
| { | ||
| TargetFramework.NET8_0, | ||
| TargetFramework.NET462, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TargetFramework.NET462 should this remain here? Becomes quite confusing between TargetFrameworks vs TargetFrameworksNetFx
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it should remain here.
Probably we should find better name for TargetFrameworksNetFx.
TargetFrameworks - TFM used for AutoInstrumentation compilation
TargetFrameworksNetFx - TFM list used to pack AutoInstrumentation for .Net Framework (packing for .NET has different, unchanged mechanic).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TargetFrameworksForNetFxRedirections?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TargetFrameworksForNetFxPacking?
| private string MapToFolderOutput(TargetFramework targetFramework) | ||
| { | ||
| return targetFramework.ToString().StartsWith("net4") ? "netfx" : "net"; | ||
| return targetFramework.ToString().StartsWith("net4") ? $"netfx" : "net"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| return targetFramework.ToString().StartsWith("net4") ? $"netfx" : "net"; | |
| return targetFramework.ToString().StartsWith("net4") ? "netfx" : "net"; |
| 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" }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need net48 and net481 too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
| else | ||
| { | ||
| Logger::Warn( | ||
| "DetectFrameworkVersionTableForRedirectsMap: Old .Net Framework detected, use 462 as fallback"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| "DetectFrameworkVersionTableForRedirectsMap: Old .Net Framework detected, use 462 as fallback"); | |
| "DetectFrameworkVersionTableForRedirectsMap: Old .NET Framework detected, use 462 as fallback"); |
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. |
| int frameworkVersion = 462; | ||
|
|
||
| HKEY hKey = nullptr; | ||
| LONG result = RegOpenKeyExW(HKEY_LOCAL_MACHINE, L"SOFTWARE\\Microsoft\\NET Framework Setup\\NDP\\v4\\Full\\", 0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
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. |
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:
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
netfxfolders. 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
CentralPackageTransitivePinningEnabledfor newly created OpenTelemetry.AutoInstrumentation.Assemblies.NetFramework.csproj was enabled - with it transient auto-generated packages were removed fromOpenTelemetry.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
Checklist
CHANGELOG.mdis updated.Open questions
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: