Alternative to Assembly.ReflectionOnlyLoad() for .NET Core tasks
#8650
-
|
Hi, we are building MSBuild task which will register Microsoft Office add-ins in an assembly. Addins are classes which are visible to COM, have GUID and ProgId and must be registered in Windows Registry. [ComVisible(true)]
[Guid("01BF0B35-5D6E-4873-84F1-D925F39BD3AC")]
[ProgId("AcmeCorp.Net48Sample.AcmeAddin")]
public class AcmeAddin : COMAddin
{ }Our task for MSBuild v15 and .NET Framework 4.6.2 is using What is a good alternative for this API for .NET Core as We need to load the assembly in isolation as addins may reference many other libraries. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
System.Reflection.MetadataLoadContext would ensure that nothing is executed from the assembly. However, it will require you to provide mscorlib.dll or equivalent. If you cannot provide that, then System.Reflection.Metadata.MetadataReader could read the types, attributes etc. without resolving any references, but its API is very different. Does your MSBuild task immediately register the add-ins in the Registry of the computer on which the task is run, or does it set up a registration script for later execution? In the former case, the task requires Windows anyway, so consider building a .NET Framework executable and running that out of process from the task. |
Beta Was this translation helpful? Give feedback.
-
|
The task will register the addin immediately and it is for Windows only. Registering it using executable sounds interesting, it definitely helps with assembly isolation. |
Beta Was this translation helpful? Give feedback.
System.Reflection.MetadataLoadContext would ensure that nothing is executed from the assembly. However, it will require you to provide mscorlib.dll or equivalent. If you cannot provide that, then System.Reflection.Metadata.MetadataReader could read the types, attributes etc. without resolving any references, but its API is very different.
Does your MSBuild task immediately register the add-ins in the Registry of the computer on which the task is run, or does it set up a registration script for later execution? In the former case, the task requires Windows anyway, so consider building a .NET Framework executable and running that out of process from the task.