I started with a very sophisticated system of clients and servers with COM references and other things, and I've cut down and down until I realized I can't even get Microsoft sample code to work for registration free COM activation of a managed COM server written in C#.
Server code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices.ComTypes;
using System.Runtime.InteropServices;
using System.ComponentModel;
namespace ClassLibrary1
{
[Guid("A7AC6D8C-FF17-4D2C-A3B1-2C8690A8EA04")
,ComVisible(true)]
public interface IClass1
{
[DispId(1)]
string DummyFunction(string inputValue);
}
[Guid("81723475-B5E3-4FA0-A3FE-6DE66CEE211C"),
ClassInterface(ClassInterfaceType.None),
ComDefaultInterface(typeof(IClass1)),
ComVisible(true)]
public class Class1 : IClass1
{
public string DummyFunction(string inputValue)
{
return inputValue.Substring(0, 1) + " Inserted " + inputValue.Substring(1);
}
}
}
Client VB6 Code:
Dim c As ClassLibrary1.Class1
Set c = New Class1
MsgBox c.DummyFunction("Ben")
Client C++ Code:
#include "stdafx.h"
#import <ClassLibrary1.tlb> raw_interfaces_only
using namespace ClassLibrary1;
int _tmain(int argc, _TCHAR* argv[])
{
IClass1Ptr p;
HRESULT hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);
hr = CoCreateInstance(__uuidof(Class1), NULL, CLSCTX_INPROC_SERVER, __uuidof(IClass1), (void **)&p);
if (FAILED(hr))
{
_tprintf_s(_T("Error %x\n"), hr);
CoUninitialize();
return 1;
}
_bstr_t b = _T("Bobby");
BSTR b2;
p->DummyFunction(b, &b2);
wprintf_s(L"%s\n", b2);
p->Release();
CoUninitialize();
return 0;
}
Both of the clients work fine when I remove all Reg-Free COM code and register the ClassLibrary1.dll with regasm /codebase.
Then I unregister ClassLibrary1, and try to introduce Reg-Free COM for the VB6 client with the file Project1.exe.manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32" name="Project1" version="1.0.0.0" />
<dependency>
<dependentAssembly>
<assemblyIdentity name="ClassLibrary1" version="1.0.0.0" />
</dependentAssembly>
</dependency>
</assembly>
And ClassLibrary1.manifest:
<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity version="1.0.0.0" name="ClassLibrary1" />
<clrClass clsid="{81723475-B5E3-4FA0-A3FE-6DE66CEE211C}" name="ClassLibrary1.Class1" tlbid="{F8A2D334-5BBB-4007-8308-A1417052E6D6}"></clrClass>
<file name="ClassLibrary1.dll" ></file>
</assembly>
Now I get Error 429 (ActiveX Component can't create object) sometimes, and (inexplicably) an automation error other times:
Run-time error '-2146234304 (80131040)':
Automation Error
then I try to introduce COM Isolation into the C++ client:
Now when I run the C++ client, the output is merely
Error 800401f9
After many trials working through various samples with Microsoft support, I have identified many pitfalls that arise in attempting to implement a managed COM server with an unmanaged C++ COM client. Here are the key pieces of information that I recall, which can be applied to the sample code in the question to make sure it works.
The client should not use the Isolated COM settings in the C++ project. My memory is fading, but Microsoft support tells me this is for something else -- I think for developing an isolated COM interface to an un-managed COM server instead of a managed COM server. Although this is not at all clear from its description at https://msdn.microsoft.com/en-us/library/zzbcs3x5(v=vs.120).aspx.
The client may select "Yes" or "No" for the "Embed Manifest" setting, but if "Yes" is selected, then the manifest that includes the dependent assembly information must be provided as an input manifest file. If the embedded manifest does not contain dependent assembly information, then any external manifest file would be ignored. Also, make sure that the configuration (Debug, for example) being edited matches the configuration being tested!
If the COM server is signed with a key (is strongly named), then the assemblyIdentity element in both the client manifest and the server manifest must contain a publicKeyToken, otherwise HRESULT error 0x80131040 will occur during CoCreateInstance.
Embedding the RT_MANIFEST resource as a Win32 resource in managed code is not easy with Visual Studio 2013 because C# and VB.NET projects tend to want to embed resources as managed .NET resources, not Win32 resources (you can verify this by opening the DLL output file with the resource viewer and notice that .NET executables generally get a version resource and not much else, even if the project has a manifest file included). One way to get around this is to create a RC file like this:
-
#define RT_MANIFEST 24
#define MANIFEST_RESOURCE_ID 1
MANIFEST_RESOURCE_ID RT_MANIFEST ClassLibrary1.manifest
Then add a pre-build step like this:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\rc.exe" "$(ProjectDir)ClassLibrary1.rc"
Then in the project settings "Application" tab, change the "Resources" to use ClassLibrary1.res instead of "Icon and manifest". But this comes with problems: firstly, the path to RC.EXE is not easy to define without hard-coding it; secondly, the version information from AssemblyInfoCommon will be ignored because the resources in the RC file totally replace all Win32 resources that would be generated by the .NET compiler.
Another possibility is to simply keep the server COM DLL manifest file separate and not embed it as a resource. I have read that this may not be reliable, but it works on Windows 7 Enterprise 64-bit SP1.
To ensure that the unmanaged client loads the proper .NET runtime, it needs a config file (ConsoleApplication1.exe.config) that defines how to load .NET. For .NET 4.5, I have seen this work:
-
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
While for .NET 3.5, it seems useLegacyV2RuntimeActivationPolicy needs to be switched:
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="false">
<supportedRuntime version="v3.5"/>
</startup>
</configuration>
It's important to check that all the framework and CLR versions are in sync. And it's important to understand that the CLR versions are not the same as the framework versions. For example, if you want to build a managed COM server on .NET 3.5, the CLR version (runtimeVersion) should be "2.0.50727", but the .NET version (supportedRuntime) should be "v3.5".
Make sure that the COM server's .NET Framework target version matches the client's supportedRuntime. If it is being built from the command line, it may not be picking up the framework version from the Visual Studio project file (for example, if you are running the C# of VB.NET compiler directly instead of calling MSBuild), make sure that the build is targeting the right version of the framework.
I have not validated all the above yet, but intend to walk through this whole process soon to verify that I caught everything. Here is what I ended up with that I haven't mentioned yet:
ConsoleApplication1.exe.manifest (in source directory, gets copied or embeded into output directory at build time)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
type = "win32"
name = "ConsoleApplication1"
version = "1.0.0.0" />
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="ClassLibrary1"
version="1.0.0.0"
publicKeyToken="541b4aff0f04b60a"/>
</dependentAssembly>
</dependency>
</assembly>
ClassLibrary1.manifest
<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity type="win32" name="ClassLibrary1" version="1.0.0.0" publicKeyToken="541b4aff0f04b60a" />
<clrClass clsid="{81723475-B5E3-4FA0-A3FE-6DE66CEE211C}" progid="ClassLibrary1.Class1" threadingModel="both" name="ClassLibrary1.Class1" runtimeVersion="v2.0.50727"></clrClass>
</assembly>
EDIT:
Now to go through and validate every detail with full error message info etc.
I start by creating a single solution containing two projects with all default values and the code shown in the question. I begin with no manifest files nor any of the project settings mentioned in the question, and will explicitly call out when I am making these changes in the process below. These are the steps and errors that are on the path to making this project work.
Error: "Class1: Undeclared identifier". Need to run a Developer Command Prompt and execute the following command line in order to get a TLB file that the C++ code can import: tlbexp ClassLibrary1.dll
Move the TLB file into the ConsoleApplication1 project directory and re-build. Same Error.
Replace the angle brackets on #import <ClassLibrary1.tlb> raw_interfaces_only with quotes, so it reads #import "ClassLibrary1.tlb" raw_interfaces_only. Rebuild: Success.
At this point, if we run we get Error 80040154 (Class not registered) because we have not registered the component nor set up registration-free COM.
Knowing that trying to set up Isolated COM in the client would present Error 800401f9 we'll skip that and just try to create a client manifest. Create a new text file with the following content, and save it as ConsoleApplication1.exe.manifest in the ConsoleApplication1 project directory:
-
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32" name="ConsoleApplication1" version="1.0.0.0" />
<dependency>
<dependentAssembly>
<assemblyIdentity name="ClassLibrary1" version="1.0.0.0" />
</dependentAssembly>
</dependency>
</assembly>
At this point it appears the steps mentioned earlier in this solution are a little over-complicated. You can simply include the manifest file in the project by showing hidden files, and using the "Include In Project" command on the manifest file.
Running at this point would present the error message "The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command line sxstrace.exe tool for more detail." This is partly because we haven't put ClassLibrary1.dll anywhere where ConsoleApplication1.exe can find it. The parsed sxstrace output at this point looks like this:
-
INFO: Parsing Manifest File C:\Users\bmarty\Documents\Visual Studio 2013\Projects\RegFreeCOM\Debug\ConsoleApplication1.exe.
INFO: Manifest Definition Identity is ConsoleApplication1,type="win32",version="1.0.0.0".
INFO: Reference: ClassLibrary1,version="1.0.0.0"
INFO: Resolving reference ClassLibrary1,version="1.0.0.0".
INFO: Resolving reference for ProcessorArchitecture ClassLibrary1,version="1.0.0.0".
INFO: Resolving reference for culture Neutral.
INFO: Applying Binding Policy.
INFO: No binding policy redirect found.
INFO: Begin assembly probing.
INFO: Did not find the assembly in WinSxS.
INFO: Attempt to probe manifest at C:\Users\bmarty\Documents\Visual Studio 2013\Projects\RegFreeCOM\Debug\ClassLibrary1.DLL.
INFO: Attempt to probe manifest at C:\Users\bmarty\Documents\Visual Studio 2013\Projects\RegFreeCOM\Debug\ClassLibrary1.MANIFEST.
INFO: Attempt to probe manifest at C:\Users\bmarty\Documents\Visual Studio 2013\Projects\RegFreeCOM\Debug\ClassLibrary1\ClassLibrary1.DLL.
INFO: Attempt to probe manifest at C:\Users\bmarty\Documents\Visual Studio 2013\Projects\RegFreeCOM\Debug\ClassLibrary1\ClassLibrary1.MANIFEST.
INFO: Did not find manifest for culture Neutral.
INFO: End assembly probing.
ERROR: Cannot resolve reference ClassLibrary1,version="1.0.0.0".
ERROR: Activation Context generation failed.
End Activation Context Generation.
Copying the ClassLibrary1.dll file into the same directory as ConsoleApplication1.exe doesn't change anything because we haven't provided any manifest for the file by which the COM dependency can be identified. So the next step is to create a manifest for ClassLibrary1. One version of ClassLibrary1.manifest is already present in the question. Let's try that one by creating a text file with that content and saving it in the ClassLibrary1 project directory as ClassLibrary1.manifest. To include it in the project, let's try the same simple "Include in Project" command (again, turning on the visibility of hidden files to make that possible). Now what happens when copying the new ClassLibrary1.dll to the directory with ConsoleApplication1.exe and running?
The same error and sxstrace results occur because a manifest file in a managed DLL does not get embedded as a Win32 resource, as you can verify by opening the DLL file with Visual Studio, which shows the file's Win32 resources. It shows the version resource and nothing else. So let's exclude the manifest from the ClassLibrary1 and just copy the manifest file over to ConsoleApplication1.exe's location as an external file instead.
Success! The program runs and completes normally. But what if we want to use a component built with a different version of .NET framework. Or maybe your test isn't working at this point because your Visual Studio defaulted to a different version? Right now I see that my ClassLibrary1 project defaulted to .NET 3.5. What happens if I change it to 4.0, rebuild, copy and run again?
Error 8013101b occurs. That corresponds (according to a google search) to COR_E_NEWER_RUNTIME which also means "A module specified in the manifest was not found." This happens when, for example, an EXE that loaded .NET 2.0 is trying to reference a DLL built with .NET 4.0. So now we have to tell the un-managed client EXE which version of the .NET framework to load as it resolves its COM reference. This is done with a config file named ConsoleApplication1.exe.config. Just create a new text file and save it with that name in the ConsoleApplication1.exe directory. It has the following content:
-
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
The same error would still occur if useLegacyV2RuntimeActivationPolicy were excluded in this case. Unfortunately, I don't fully understand why, but I suspect it has something to do with the newer v4.0 runtime activation policy defaulting to loading CLR v2.0 if the executable being loaded does not explicitly reference .NET 4.0 (which un-managed code does not because it doesn't explicitly reference .NET period).
Success again! But wait, there's more. What if your COM dll is signed with a key (has a strong name)? Let's add a key to ClassLibrary1, configure it to be used in signing the DLL on the project's "Signing" tab, and see what happens when we copy the updated DLL to ConsoleApplication1.exe's directory.
Now we get Error 80131040 ("The located assembly's manifest definition does not match the assembly reference"). And sxstrace, and fuslogvw are frustratingly unhelpful here in yielding any information about what is going on. Fortunately, I now know, in this particular reg-free-com scenario, it's caused by the lack of the publicKeyToken attribute on the assemblyIdentity elements describing ClassLibrary1 (in both manifest files). But how do you get the publicKeyToken value? Run sn -T ClassLibrary1.dll from a developer command prompt. After updating ClassLibrary1.manifest and ConsoleApplication1.exe.manifest, remember to rebuild ConsoleApplication1.exe if the manifest is embedded, and to copy ClassLibrary1.manifest to the ConsoleApplication1.exe directory. Run again and?
I went through a few more gyrations of error solving with the help of sxstrace, but that was due to stupid errors. For the benefit of others who make stupid errors, here are some more things to be aware of if you're getting sxstrace errors: a) make sure you're using the attribute publicKeyToken and not some other ridiculous name like privateKeyToken; b) Make sure that all the attributes you specified in the assemblyIdentity on the server side manifest match those on the client side manifest, and that you don't have type="win32" specified on one but not the other.
Success! The output is B Inserted obby
I should also note that the VB6 client also works by using the following files along with the VB6 client:
Project1.exe.config:
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
Project1.exe.manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32" name="Project1" version="1.0.0.0" />
<dependency>
<dependentAssembly>
<assemblyIdentity name="ClassLibrary1" version="1.0.0.0" publicKeyToken="541b4aff0f04b60a" />
</dependentAssembly>
</dependency>
</assembly>
However, there does seem to be a tendency to report "ActiveX Component Can't Create Object" (Runtime error 429) in rare cases when the executable is built and run before creating the configuration and manifest files. Rebuilding the EXE file seems to fix it, but then I can't get the problem to come back, so it's hard to identify a specific cause.
I thought I was a reasonably good problem solver, but something about the numerous moving parts and numerous unhelpful error codes and error messages reported in reg-free com configuration problems makes this nearly impossible to figure out without some solid experience, inside knowledge or Microsoft source code. Hopefully this answer will help others acquire similar experience. Please extend this answer if you learn more!
Addendum 1
The managed COM server's manifest can be properly and easily embedded if you use the "Add"->"New Item..." command on the project to add an "Application Manifest File". This adds a file called app.manifest to the project. But the real tricky part is that it does so in a way that cannot be replicated any other way via the Visual Studio UI, except through one screwy work-around. Since the "Manifest" field on the "Application" tab of the project settings window is disabled for "Class Library" type projects, the manifest, which would normally be set here, cannot be set for a class library. But you can temporarily change the project to a Windows Application, change the Manifest selection here, then restore it to a Class Library. The setting will stick so the selected manifest gets properly embedded. You can verify the setting in a text editor by viewing the project file. Look for:
<PropertyGroup>
<ApplicationManifest>app.manifest</ApplicationManifest>
</PropertyGroup>
Addendum 2
Error 0x80131040 can still occur with all the above precautions taken. To help narrow down the cause of this, it helps to use the fusion log viewer to see more information about what is happening as assemblies are being loaded and resolved. Google "Fuslogvw" for more information about how to view this log (fuslogvw.exe is a utility provided when Visual Studio is installed). It's also important to realize that this application, by default, apparently does not show any information until you configure it to log information to files, reproduce the problem, then restart the application to read the log files after they are produced. And, according to MSDN documentation, it's also important to remember to run this utility as administrator.
Once you've passed all the hurdles to running fuslogvw.exe, you may see something like this in the log:
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: The assembly reference did not match the assembly definition found.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
Despite the fact that the COM server's manifest file listed the version as 1.0.0.0, that is not the (only) version used when binding from a COM client reference to the server. My client EXE file was trying to reference 1.0.0.0, which exactly matched the version in the COM server's manifest file, but it did not match the .NET version of the DLL. After correcting both the client and server manifest files to reflect the version actually in the .NET server DLL, then error 0x80131040 went away, and fuslogvw.exe was the key to identifying that as the source of the problem.
If the Client manifest is in sync with the actual .NET DLL version, but the server DLL's manifest file does not reflect this version, a different error will occur:
The application has failed to start because its side-by-side
configuration is incorrect. Please see the application event log or
use the command-line sxstrace.exe tool for more detail.
Addendum 3
Error 0xc0150002 or the following message may be reported:
The application was unable to start correctly (0xc0150002), Click OK
to close the application.
I have seen this occur in a case where the client manifest was embedded in an unmanaged DLL rather than an unmanaged EXE, and the manifest's assemblyIdentity element did not exactly match the server's assemblyIdentity. The client had an extra processorArchitecture="x86" in it that the server did not specify, causing a mismatch. Unfortunately I don't know how to learn this without luckily thinking to check the manifest files to see that they match (or reading this article). That error doesn't clearly point to a manifest file being the source of the problem, so you just have to be aware that there's a possible correlation between that error message and this cause.
Addendum 4
I have seen external manifest files get completely ignored yielding a completely empty sxstrace log, even when the executables involved have no embedded manifests. This can apparently happen as a result of the activation context cache (a problem documented at http://csi-windows.com/blog/all/27-csi-news-general/245-find-out-why-your-external-manifest-is-being-ignored). To work around this problem you can use the following command to touch the date stamp of the file whose manifest is being ignored:
copy /b myfile.exe+,,
Addendum 5
I have seen another hard-to-explain Class Not Registered error (0x80040154 - REGDB_E_CLASSNOTREG) that occurs when calling CoCreateInstance under the following conditions:
An CPP file contains a constructor for a class that is instantiated in global scope so dynamic initialization will call the constructor during DllMain if the /clr switch is not applied to the CPP file, or during .cctor if the /clr switch is applied to the file.
The DLL has an embedded manifest to make it be able to reference the COM class being created via Reg-Free COM.
The COM DLL is implemented in managed code (with a COM-Callable Wrapper aka CCW) in .NET 2.0.
The EXE that loaded the DLL does not have a Reg-Free Manifest referencing the created COM class.
The COM DLL is not registered with regasm.
The CPP file calling CoCreateInstance has the /clr switch applied to the C++ compiler settings.
If any of the last 3 conditions are altered, the problem goes away. (Additionally, if the last condition is altered, you may get a loader lock due to #1 -- read about loader lock and it's relation to CLR at Initialization of Mixed Assemblies). So if you are encountering a Class Not Registered error in similar circumstances, consider whether you can alter any of those last 3 conditions to resolve the error.
Note: I'm having a hard time nailing down the behavior of #6. It seems the effect of switching this also depends the state of #1. It looks like calling the constructor (including its CoCreateInstance) after the DLL is fully loaded still causes Class Not Registered whereas calling the constructor during the DLL initialization will succeed if the /clr switch is not specified. My solution for the time being is to re-code the client CPP file in managed C++ since it was a relatively simple interface class between the COM component and the rest of the un-managed code. So now there's no more COM in this client, just a .NET reference.
To all my frustrations, BlueMonkMN's explanation was really useful but yet I encountered the Class not registered message.
I have a .NET 4.6 COM interop Dll and a C++ client which makes use of Registration Free COM by the means of Windows SxS technology. Assembly manifest was embedded inside the COM Dll and the application manifest was put outside, as a separate .manifest file.
Everything was working as advertised but it started getting the Class not registered message during CreateInstance when any one of the following happens.
Copy the interop COM Dll along with C++ client executable and the
manifest file to some other directory.
Make non COM related changes to C++ client and then rebuild the
application.
In this situation, to add insult to injury, sxstrace log was empty, application event log (eventvwr) didn't report any SideBySide error and the Assembly Binding Log Viewer (FUSLOGVW.exe) didn't show anything from the C++ client application.
Let me add another Addendum to BlueMonkMN's answer ablove.
Addendum 6
What I understand from my so far experiments is that, in such a case, the Activation Context for the C++ client application is not getting created.
In such a situation one need to create the Activation context by themselves.
Following code is put inside the C++ client application, after a call to CoInitialize(0); and before making any call to CreateInstance.
ACTCTX context;
memset(&context, 0, sizeof(context));
context.cbSize = sizeof(context);
context.lpSource = L"CPPClient.exe.manifest";
context.lpAssemblyDirectory = L"D:\\code\\vs2017\\CPPClient\\Debug";
context.dwFlags = ACTCTX_FLAG_ASSEMBLY_DIRECTORY_VALID;
HANDLE hActCtx = CreateActCtx(&context);
ULONG_PTR cookie = 0;
BOOL result = ActivateActCtx(hActCtx, &cookie);
//Rest of the code goes here.
As a cleanup measure, following piece of code is put just before a call to CoUninitialize();
DeactivateActCtx(0, cookie);
ReleaseActCtx(hActCtx);
Now it sounds good. Side by Side is working very well. If anything goes wrong, then it can be seen in sxstrace or in application event log or in Assembly Binding Log Viewer.
I work on an application with similar requirements, i.e. I need to activate a reg-free managed COM server (located it a DLL written in C# / .net v4.8) from an unmanaged client process (written in C++), and the C# DLL should be located in directory outside the C++ application dir.
As of now, reg-free COM server activation of the managed COM server DLL only works for me when I both
activate the COM server using a custom activation context (CreateActCtx / ActivateActCtx etc.) with context.lpAssemblyDirectory = ... set to the COM DLL directory and
change the assembly probing algorithm on the .net side so that it's able to locate my C# DLL, which it doesn't do by default.
Regarding the latter, I currently do this by adding an application configuration file for the C++ EXE in which I enabe developmentMode and I also set the DEVPATH environment variable to the same value as `context.lpAssemblyDirectory'.
This works for me because I only need the C# DLL directory to be outside the C++ EXE directory during development.
Note that there are also other options to change the .net assembly probing algorithm. For example you could
add an application configuration file and specify additional sub(!)-directories where to search. Works only for relative paths / actual subdirs of the application dir
add a custom .net assembly resolver (see AssemblyResolve) - which needs to be loaded by the .net runtime before it actually attempts to locate the C# COM server assembly. I haven't yet looked into how to make this work though...
I have a tool that creates .NET resource assemblies programmatically, the tool is written in C# and is compiled using .NET v4.0. On occasion this tool needs to generate resource assemblies that target .NET v3.5. The online doc suggests that this can be done using the TypeNameConverter property of the ResourceWriter object I am using to write the resources with but I have had no luck finding an example of how this is actually done. Any help would be much appreciated.
For anyone else wanting to do something similar I've found a way to do this. I've changed my tool so that it's built against ('targets') .NET v3.5 and I control which CLR the tool gets loaded into using entries in it's app.config file as shown below. By switching the order of the entries in the config file I am now able to generate CLR 2.0 resource assemblies from .NET v3.5 source assemblies and CLR 4.0 resource assemblies from .NET v4.0 source assemblies.
<?xml version="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v4.0"/>
<supportedRuntime version="v2.0.50727"/>
</startup></configuration>
Good link here about app.config entries: https://msdn.microsoft.com/en-us/library/jj152935%28v=vs.110%29.aspx
In hindsight I probably should have mentioned in the earlier description of the problem that I didn't need to change the CLR target between the source assembly and it's resource assembly, just needed consistency between the two.
I have a class library project, I have to reference an assembly in my class library project which targets v2.0.50727, then ultimately calling my class library from a project which is using .Net 4 version.
When the application runs, it gives error
“Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.”
I know i can add attributes in app.config to avoid this error, but in my case, this is class library which has no app.config.
I tried changing my class library to .net framework 2, but it is still showing error.
When I change target framework of main application from .net 4 to .net 3.5, compiler gives error on following line:
using System.ComponentModel.Composition;
What should I do ?
I ended up with changing my DLL to form-less winform EXE file which can accept command line arguments to replicate class library constructor arguments functionality. I supplied following attributes in my exe app.config file to avoid mixed mode assembly error:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
We've developed a C# 4.0 module that needs to be accessed from an unmanaged C++ program (as well as a Fortran program). The DLL gets loaded correctly and the method is available to the C++ program, but an exception gets thrown when calling the method that points to the C# code. For a visualization:
[Unmanaged C++ / Fortran Projects]
-> controller.dll (unmanaged C++ within the C++ project)
-> managed_wrapper.dll (managed C++ within the C# project)
-> C# 4.0 Project
The exception gets thrown when the controller attempts to call the managed C++ (using .NET 4.0 framework).
My suspicions are that the following configuration needs to be applied, as we encountered an error previously when creating a proof of concept:
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
I applied it correctly for the aforementioned proof of concept, but that was on a stand-alone console application. Since the unmanaged C++ program is huge and the settings are not universal for every module, I'm unable to create a MyApplication.exe.config file with the above configuration and call it day.
My question is this: Is it possible to apply that configuration to a specific DLL?
From my understanding, this is not possible.
The issue is that, the configuration setting you need to apply (useLegacyV2RuntimeActivationPolicy) is basically saying "for this entire application, no matter what the assembly requests, use CLR 4 instead.
If you could apply it to a single DLL, you'd be violating the goals here - since the goal is to force all assemblies to use CLR 4.
Edit:
After further study, there is actually a way to do this in some limited scenarios. I posted about this on my blog, but basically, you can use the CLR Hosting API to get some access to setting this from within a library.
I have been developing an application in VS2010 and compiling it for the .NET 4.0 as the target framework. After integrating a library into my application, I get the following error message when I try to compile:
Mixed mode assembly is built against version 'v1.1.4322' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.
The library works fine under .NET 3.5, but when I change my target framework to .NET 3.5, I get the following error for all my .resx files:
Error 1 Object reference not set to an instance of an object.
I tried ctrl-h Version=4.0.0.0 to Version=3.5.0.0 but that doesn't seem to work. Is there anything I can do other that create a new application?
Open your .resx file with the XML editor instead of the resources editor, and search for System.Windows.Forms, Version=4.0.0.0. There should be 2 instances of this string. Replace 4.0.0.0 with 2.0.0.0 and save the file. Your resources should work correctly now.
Note that you can also go back to .NET 4 and try to add the following to your App.config to allow older assemblies to run on the new runtime:
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
You should be able to make this work by configuration settings in app.Config.
Just add the useLegacyV2RuntimeActivationPolicy="true" flag to your appConfig in the startup section. This causes the .NET 4 runtime to handle older mixed-mode assemblies.
Open Properties of project. Then select the Resources. Delete all resource images and insert them again. now compile it. Your project is working now.. :)