-
-
Notifications
You must be signed in to change notification settings - Fork 274
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
Assembly attributes make apps using Costura crash at startup when CreateTemporaryAssemblies="true"
#703
Comments
In .NET Core, this would be possible by creating a specific load context for the assemblies to be loaded. We do something similar in Orc.Extensibility where we check each (potential) extension in a separate load context. Once accepted, we can load them into the primary application so they can interact with the system. In full .NET, this would require separate app domains, which at this stage I would not invest in (if I were you). Are the attributes in the main app or in depending libraries? In the 2nd case, you could determine the order or use LoadAssembliesOnStartup to force loading of specific assemblies first. Another option that might work: use reflection only to determine the attribute. I think, in this case, it will not need the attribute stuff (but we should test before making this assumption). |
I just got bitten by this again on another project, so I'm looking at it again. Could you please elaborate on this?
I'm not sure to understand what you mean. |
I found a workaround that allows you to use both |
This makes TempFileTests.ExecutableRunsSuccessfully fail
Is this something we can detect at compile time (e.g. if we use this combination, fail the build and explain to use LoadAtModuleInit + CosturaUtility? |
Please check all of the platforms you are having the issue on (if platform is not listed, it is not supported)
Component
Costura 5.3.0
Version of OS(s) listed above with issue
Windows 10
Steps to Reproduce
Project layout:
MyApp.csproj:
FodyWeavers.xml:
Program.cs:
MyLibrary.csproj:
MyAssemblyAttribute:
Run this project with
dotnet run --project MyApp\MyApp.csproj
Expected Behavior
The program runs and
Hello World!
is printed on the console output.Actual Behavior
The program crashes with the following exception:
Additional notes
I discovered this issue while using the Microsoft.CrmSdk.XrmTooling.CoreAssembly package and generating Early Bound Xrm classes with the Early Bound Generator which adds this attribute in the generated organization service context class:
I need
CreateTemporaryAssemblies="true"
because the CrmSdk absolutely wants to access the assembly on disk. 😠When implementing #638 I did not realize that GetCustomAttribute could potentially call into the assembly resolving mechanism.
So this is a catch-22 situation where we need to access the
TargetFrameworkAttribute
but accessing it fires theAssemblyResolve
before we can set it up. 😕Workarounds
There are two workarounds I can think of.
CreateTemporaryAssemblies="true"
.Unfortunately, depending on the situation, neither of them may be possible.
Possible solution
I have an idea to solve this issue but it's so complicated I'm not sure it's worth trying to implement. It would go like this:
ILtemplate
)ILTemplateWithTempAssembly
that loads dlls from the disk cache.This is really convoluted and I hope I can think of a better solution. For the mean time I have deleted
Microsoft.Xrm.Sdk.Client.ProxyTypesAssemblyAttribute
which is not absolutely required for my usage.The text was updated successfully, but these errors were encountered: