Skip to content
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

GAC - install and uninstall clarification #1906

Closed
Kielek opened this issue Jan 9, 2023 · 4 comments · Fixed by #1986
Closed

GAC - install and uninstall clarification #1906

Kielek opened this issue Jan 9, 2023 · 4 comments · Fixed by #1986
Assignees

Comments

@Kielek
Copy link
Contributor

Kielek commented Jan 9, 2023

Hi @Kielek @pellared , with v0.5.1-beta.3, I can not reproduce this issue, even without registering netfx assemblies in GAC.

I have 2 quick questions about registering / unregistering assemblies in GAC:

  • Some assemblies below did not get added to GAC. is it because they are not strong named? any impact if they are not showing up in GAC?
    • netstandard.dll
    • grpc_csharp_ext.x64.dll
    • grpc_csharp_ext.x86.dll
  • if I have an assembly already in GAC before installing dotnet auto-instrumentation, and this assembly is duplicated with an assembly under tracer-home/netfx/ folder. what will happen to it after installing dotnet auto-instrumentation? and what will happen to it after uninstalling auto-instrumentation? will it be removed from GAC by auto-instrumentation uninstall?

for info, I used this command to register assemblies in GAC:

        # Register .NET Framweworks dlls in GAC
        [System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a") | Out-Null
        $publish = New-Object System.EnterpriseServices.Internal.Publish 
        $dlls = Get-ChildItem -Path .\netfx\ -Filter *.dll -File
        foreach ($dll in $dlls) {
            $publish.GacInstall($dll.FullName)
        }

and I used command below to unregister assemblies from GAC:

    [System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a") | Out-Null
    $publish = New-Object System.EnterpriseServices.Internal.Publish 
    $dlls = Get-ChildItem -Path .\netfx\ -Filter *.dll -File
    foreach ($dll in $dlls) {
        $publish.GacRemove($dll.FullName)
    }

before auto-instrument install, my GAC:
gac.1.txt
after auto-instrument install, my GAC:
gac.2.txt

Originally posted by @muhaook in #1858 (comment)

@muhaook
Copy link

muhaook commented Jan 9, 2023

Thanks @Kielek , I tested 0.5.1-beta3 without registering to GAC and it seemed working well. I wonder anything (new features/bug fixes) we will lose if we do not register to GAC?

@pjanotti
Copy link
Contributor

pjanotti commented Jan 9, 2023

Hi @muhaook,

I wonder anything (new features/bug fixes) we will lose if we do not register to GAC?

  1. If there is an assembly that is instrumented via monkey patching) and that assembly is loaded as domain-neutral we need the instrumentation assembly to be in the GAC so we can also load it as domain-neutral. Notice that you can load assemblies as domain-neutral directly into your app without registering them in the GAC, however, for injecting code it would be much harder. You can see the effect of lacking the registration by removing this line in the DomainNeutralTests class.
  2. For strong-named apps if they ship some version of an assembly used by OTel Auto-Instrumentation the automatic version redirect will fail if the version that we are redirecting to, the one that we ship, is not in the GAC. In other words, redirection in this case is only possible for assemblies that are registered in the GAC.

Some assemblies below did not get added to GAC. is it because they are not strong named? any impact if they are not showing up in GAC?
netstandard.dll
grpc_csharp_ext.x64.dll
grpc_csharp_ext.x86.dll

The grpc_cshart_*.dll ones are native DLLs and can't be registered on the GAC. The netstandard.dll is only a redirector itself and it is shipped with any app that needs it. Perhaps we should skip those silently to avoid any confusion about them.

if I have an assembly already in GAC before installing dotnet auto-instrumentation, and this assembly is duplicated with an assembly under tracer-home/netfx/ folder. what will happen to it after installing dotnet auto-instrumentation? and what will happen to it after uninstalling auto-instrumentation? will it be removed from GAC by auto-instrumentation uninstall?

This actually depends on how the assembly was added to the GAC. If the duplicated assemblies were added to the GAC by a MSI they aren't removed by Publish.GacRemove - it doesn't matter which GAC installation happened first (MSI or Publish.GacInstall). Assemblies added to the GAC only via Publish.GacInstall are not protected in the same way and multiple additions from different locations for the same assembly are clobbered by a single Publish.GacRemove.

Let's know if you still have questions about it.

[EDIT 00: Clarified what happens when the same assembly is installed multiple times into the GAC]

@muhaook
Copy link

muhaook commented Jan 9, 2023

Thanks @pjanotti , very helpful!
I do not have further questions. Please feel free to close this issue (I do not have permissions to do so)

@pjanotti
Copy link
Contributor

@muhaook I did an edit to my earlier comment to clarify what happens when auto-instrumentation removes the assemblies from the GAC.

I'm keeping this open for now to track some pending doc updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants