Mixing
Create AnyCPU metadata-only assembly from C++/CLI assembly
Is there a way to take an existing .NET assembly, compiled to either x86 or x64, and create another assembly with the same API but compiled as AnyCPU? The new assembly will never actually be executed; it will only be used as a compile-time reference.
Background
I have a .NET assembly that was written in C++/CLI. I'm putting it into a nuget package, using nuget's runtimes and ref folders to handle the 32 vs 64 bit issue. Normally the assemblies in the ref folder are compiled as AnyCPU, but that isn't an option for C++ assemblies. For now I've got a copy of the 32 bit version in the ref folder, but that causes a warning when included in an x64 project:
There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "c:...myassembly.dll" "x86".
I realize this won't cause any problems at runtime, but I'd like to get rid of the warning if possible. If this were written in C# or VB I'd be able to use CorFlags to turn it into an AnyCPU assembly, but that trick doesn't work with C++ assemblies. When I set the ILONLY flag on a 32 bit C++ assembly, Visual Studio is no longer able to load the assembly at all.
So can anyone suggest how to create a version of this assembly that would be suitable for use as a compile time reference in a nuget package?
.net nuget c++-cli
asked Nov 20 '18 at 0:47
DarrylDarryl
4,54511627
add a comment |
Is there a way to take an existing .NET assembly, compiled to either x86 or x64, and create another assembly with the same API but compiled as AnyCPU? The new assembly will never actually be executed; it will only be used as a compile-time reference.
Background
I have a .NET assembly that was written in C++/CLI. I'm putting it into a nuget package, using nuget's runtimes and ref folders to handle the 32 vs 64 bit issue. Normally the assemblies in the ref folder are compiled as AnyCPU, but that isn't an option for C++ assemblies. For now I've got a copy of the 32 bit version in the ref folder, but that causes a warning when included in an x64 project:
There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "c:...myassembly.dll" "x86".
I realize this won't cause any problems at runtime, but I'd like to get rid of the warning if possible. If this were written in C# or VB I'd be able to use CorFlags to turn it into an AnyCPU assembly, but that trick doesn't work with C++ assemblies. When I set the ILONLY flag on a 32 bit C++ assembly, Visual Studio is no longer able to load the assembly at all.
So can anyone suggest how to create a version of this assembly that would be suitable for use as a compile time reference in a nuget package?
.net nuget c++-cli
asked Nov 20 '18 at 0:47
DarrylDarryl
4,54511627
I was thinking about this pure attribute, ILONLY should do it, but then you have to avoid tagging in any way the platform. Didn't stackoverflow.com/a/28291475/9293869 answer your question. At least the second answer with the assembly loading code based on the platform on runtime could help. Basically you provide then the loading dll for nuget in the lib folder but that will load the right one with the provided code.
– JackGrinningCat
Nov 20 '18 at 12:49
If you only need it for the metadata then the platform target doesn't matter. Metadata is architecture-agnostic. You however always get code even if you don't write any, C++/CLI requires a module initializer. And that can generate a linker warning in the project in which you use the assembly, presumably what you are really worried about. If you're sure that the assembly doesn't get loaded at all at runtime then you can use Corflags.exe to override the CLR header.
– Hans Passant
Nov 22 '18 at 11:53
Thanks @HansPassant. Yes, it's the warning I'm trying to get rid of. I know it doesn't cause any problems, but I'd prefer that consumers of my nuget package don't see a warning and assume something isn't working correctly. As far as using Corflags, unfortunately that approach didn't work. Before making any changes, a 32-bit C++ assembly has CorFlags = 0x10, while an Any CPU non-C++ assembly's CorFlags are 0x01. I can add the 0x01 bit, which is the ILONLY flag, but when I do Visual Studio can no longer use the assembly as a reference. And there's no way to clear the 0x10 bit w/ CorFlags.
– Darryl
Nov 28 '18 at 18:03
You don't give me enough cues to really help you. The /clr:pure option is still available even though they've been promising for a while to kill it.
– Hans Passant
Nov 28 '18 at 18:14
I ended up using DotPeek to create a C# assembly with the same API as the real assembly. I won't go down that road again, as it was very manual and time consuming to turn that tool's output into something I could compile. But it did the job.
– Darryl
Nov 28 '18 at 20:29
add a comment |
Is there a way to take an existing .NET assembly, compiled to either x86 or x64, and create another assembly with the same API but compiled as AnyCPU? The new assembly will never actually be executed; it will only be used as a compile-time reference.
Background
I have a .NET assembly that was written in C++/CLI. I'm putting it into a nuget package, using nuget's runtimes and ref folders to handle the 32 vs 64 bit issue. Normally the assemblies in the ref folder are compiled as AnyCPU, but that isn't an option for C++ assemblies. For now I've got a copy of the 32 bit version in the ref folder, but that causes a warning when included in an x64 project:
There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "c:...myassembly.dll" "x86".
I realize this won't cause any problems at runtime, but I'd like to get rid of the warning if possible. If this were written in C# or VB I'd be able to use CorFlags to turn it into an AnyCPU assembly, but that trick doesn't work with C++ assemblies. When I set the ILONLY flag on a 32 bit C++ assembly, Visual Studio is no longer able to load the assembly at all.
So can anyone suggest how to create a version of this assembly that would be suitable for use as a compile time reference in a nuget package?
.net nuget c++-cli
asked Nov 20 '18 at 0:47
DarrylDarryl
4,54511627
Is there a way to take an existing .NET assembly, compiled to either x86 or x64, and create another assembly with the same API but compiled as AnyCPU? The new assembly will never actually be executed; it will only be used as a compile-time reference.
Background
I have a .NET assembly that was written in C++/CLI. I'm putting it into a nuget package, using nuget's runtimes and ref folders to handle the 32 vs 64 bit issue. Normally the assemblies in the ref folder are compiled as AnyCPU, but that isn't an option for C++ assemblies. For now I've got a copy of the 32 bit version in the ref folder, but that causes a warning when included in an x64 project:
There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "c:...myassembly.dll" "x86".
I realize this won't cause any problems at runtime, but I'd like to get rid of the warning if possible. If this were written in C# or VB I'd be able to use CorFlags to turn it into an AnyCPU assembly, but that trick doesn't work with C++ assemblies. When I set the ILONLY flag on a 32 bit C++ assembly, Visual Studio is no longer able to load the assembly at all.
So can anyone suggest how to create a version of this assembly that would be suitable for use as a compile time reference in a nuget package?
.net nuget c++-cli
.net nuget c++-cli
asked Nov 20 '18 at 0:47
DarrylDarryl
4,54511627
asked Nov 20 '18 at 0:47
DarrylDarryl
4,54511627
asked Nov 20 '18 at 0:47
DarrylDarryl
4,54511627
asked Nov 20 '18 at 0:47
DarrylDarryl
4,54511627
asked Nov 20 '18 at 0:47
DarrylDarryl
4,54511627
4,54511627
I was thinking about this pure attribute, ILONLY should do it, but then you have to avoid tagging in any way the platform. Didn't stackoverflow.com/a/28291475/9293869 answer your question. At least the second answer with the assembly loading code based on the platform on runtime could help. Basically you provide then the loading dll for nuget in the lib folder but that will load the right one with the provided code.
– JackGrinningCat
Nov 20 '18 at 12:49
If you only need it for the metadata then the platform target doesn't matter. Metadata is architecture-agnostic. You however always get code even if you don't write any, C++/CLI requires a module initializer. And that can generate a linker warning in the project in which you use the assembly, presumably what you are really worried about. If you're sure that the assembly doesn't get loaded at all at runtime then you can use Corflags.exe to override the CLR header.
– Hans Passant
Nov 22 '18 at 11:53
Thanks @HansPassant. Yes, it's the warning I'm trying to get rid of. I know it doesn't cause any problems, but I'd prefer that consumers of my nuget package don't see a warning and assume something isn't working correctly. As far as using Corflags, unfortunately that approach didn't work. Before making any changes, a 32-bit C++ assembly has CorFlags = 0x10, while an Any CPU non-C++ assembly's CorFlags are 0x01. I can add the 0x01 bit, which is the ILONLY flag, but when I do Visual Studio can no longer use the assembly as a reference. And there's no way to clear the 0x10 bit w/ CorFlags.
– Darryl
Nov 28 '18 at 18:03
You don't give me enough cues to really help you. The /clr:pure option is still available even though they've been promising for a while to kill it.
– Hans Passant
Nov 28 '18 at 18:14
I ended up using DotPeek to create a C# assembly with the same API as the real assembly. I won't go down that road again, as it was very manual and time consuming to turn that tool's output into something I could compile. But it did the job.
– Darryl
Nov 28 '18 at 20:29
add a comment |
I was thinking about this pure attribute, ILONLY should do it, but then you have to avoid tagging in any way the platform. Didn't stackoverflow.com/a/28291475/9293869 answer your question. At least the second answer with the assembly loading code based on the platform on runtime could help. Basically you provide then the loading dll for nuget in the lib folder but that will load the right one with the provided code.
– JackGrinningCat
Nov 20 '18 at 12:49
If you only need it for the metadata then the platform target doesn't matter. Metadata is architecture-agnostic. You however always get code even if you don't write any, C++/CLI requires a module initializer. And that can generate a linker warning in the project in which you use the assembly, presumably what you are really worried about. If you're sure that the assembly doesn't get loaded at all at runtime then you can use Corflags.exe to override the CLR header.
– Hans Passant
Nov 22 '18 at 11:53
Thanks @HansPassant. Yes, it's the warning I'm trying to get rid of. I know it doesn't cause any problems, but I'd prefer that consumers of my nuget package don't see a warning and assume something isn't working correctly. As far as using Corflags, unfortunately that approach didn't work. Before making any changes, a 32-bit C++ assembly has CorFlags = 0x10, while an Any CPU non-C++ assembly's CorFlags are 0x01. I can add the 0x01 bit, which is the ILONLY flag, but when I do Visual Studio can no longer use the assembly as a reference. And there's no way to clear the 0x10 bit w/ CorFlags.
– Darryl
Nov 28 '18 at 18:03
You don't give me enough cues to really help you. The /clr:pure option is still available even though they've been promising for a while to kill it.
– Hans Passant
Nov 28 '18 at 18:14
I ended up using DotPeek to create a C# assembly with the same API as the real assembly. I won't go down that road again, as it was very manual and time consuming to turn that tool's output into something I could compile. But it did the job.
– Darryl
Nov 28 '18 at 20:29
I was thinking about this pure attribute, ILONLY should do it, but then you have to avoid tagging in any way the platform. Didn't stackoverflow.com/a/28291475/9293869 answer your question. At least the second answer with the assembly loading code based on the platform on runtime could help. Basically you provide then the loading dll for nuget in the lib folder but that will load the right one with the provided code.
– JackGrinningCat
Nov 20 '18 at 12:49
I was thinking about this pure attribute, ILONLY should do it, but then you have to avoid tagging in any way the platform. Didn't stackoverflow.com/a/28291475/9293869 answer your question. At least the second answer with the assembly loading code based on the platform on runtime could help. Basically you provide then the loading dll for nuget in the lib folder but that will load the right one with the provided code.
– JackGrinningCat
Nov 20 '18 at 12:49
If you only need it for the metadata then the platform target doesn't matter. Metadata is architecture-agnostic. You however always get code even if you don't write any, C++/CLI requires a module initializer. And that can generate a linker warning in the project in which you use the assembly, presumably what you are really worried about. If you're sure that the assembly doesn't get loaded at all at runtime then you can use Corflags.exe to override the CLR header.
– Hans Passant
Nov 22 '18 at 11:53
If you only need it for the metadata then the platform target doesn't matter. Metadata is architecture-agnostic. You however always get code even if you don't write any, C++/CLI requires a module initializer. And that can generate a linker warning in the project in which you use the assembly, presumably what you are really worried about. If you're sure that the assembly doesn't get loaded at all at runtime then you can use Corflags.exe to override the CLR header.
– Hans Passant
Nov 22 '18 at 11:53
Thanks @HansPassant. Yes, it's the warning I'm trying to get rid of. I know it doesn't cause any problems, but I'd prefer that consumers of my nuget package don't see a warning and assume something isn't working correctly. As far as using Corflags, unfortunately that approach didn't work. Before making any changes, a 32-bit C++ assembly has CorFlags = 0x10, while an Any CPU non-C++ assembly's CorFlags are 0x01. I can add the 0x01 bit, which is the ILONLY flag, but when I do Visual Studio can no longer use the assembly as a reference. And there's no way to clear the 0x10 bit w/ CorFlags.
– Darryl
Nov 28 '18 at 18:03
Thanks @HansPassant. Yes, it's the warning I'm trying to get rid of. I know it doesn't cause any problems, but I'd prefer that consumers of my nuget package don't see a warning and assume something isn't working correctly. As far as using Corflags, unfortunately that approach didn't work. Before making any changes, a 32-bit C++ assembly has CorFlags = 0x10, while an Any CPU non-C++ assembly's CorFlags are 0x01. I can add the 0x01 bit, which is the ILONLY flag, but when I do Visual Studio can no longer use the assembly as a reference. And there's no way to clear the 0x10 bit w/ CorFlags.
– Darryl
Nov 28 '18 at 18:03
You don't give me enough cues to really help you. The /clr:pure option is still available even though they've been promising for a while to kill it.
– Hans Passant
Nov 28 '18 at 18:14
You don't give me enough cues to really help you. The /clr:pure option is still available even though they've been promising for a while to kill it.
– Hans Passant
Nov 28 '18 at 18:14
I ended up using DotPeek to create a C# assembly with the same API as the real assembly. I won't go down that road again, as it was very manual and time consuming to turn that tool's output into something I could compile. But it did the job.
– Darryl
Nov 28 '18 at 20:29
I ended up using DotPeek to create a C# assembly with the same API as the real assembly. I won't go down that road again, as it was very manual and time consuming to turn that tool's output into something I could compile. But it did the job.
– Darryl
Nov 28 '18 at 20:29
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53384685%2fcreate-anycpu-metadata-only-assembly-from-c-cli-assembly%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53384685%2fcreate-anycpu-metadata-only-assembly-from-c-cli-assembly%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I was thinking about this pure attribute, ILONLY should do it, but then you have to avoid tagging in any way the platform. Didn't stackoverflow.com/a/28291475/9293869 answer your question. At least the second answer with the assembly loading code based on the platform on runtime could help. Basically you provide then the loading dll for nuget in the lib folder but that will load the right one with the provided code.
– JackGrinningCat
Nov 20 '18 at 12:49
If you only need it for the metadata then the platform target doesn't matter. Metadata is architecture-agnostic. You however always get code even if you don't write any, C++/CLI requires a module initializer. And that can generate a linker warning in the project in which you use the assembly, presumably what you are really worried about. If you're sure that the assembly doesn't get loaded at all at runtime then you can use Corflags.exe to override the CLR header.
– Hans Passant
Nov 22 '18 at 11:53
Thanks @HansPassant. Yes, it's the warning I'm trying to get rid of. I know it doesn't cause any problems, but I'd prefer that consumers of my nuget package don't see a warning and assume something isn't working correctly. As far as using Corflags, unfortunately that approach didn't work. Before making any changes, a 32-bit C++ assembly has CorFlags = 0x10, while an Any CPU non-C++ assembly's CorFlags are 0x01. I can add the 0x01 bit, which is the ILONLY flag, but when I do Visual Studio can no longer use the assembly as a reference. And there's no way to clear the 0x10 bit w/ CorFlags.
– Darryl
Nov 28 '18 at 18:03
You don't give me enough cues to really help you. The /clr:pure option is still available even though they've been promising for a while to kill it.
– Hans Passant
Nov 28 '18 at 18:14
I ended up using DotPeek to create a C# assembly with the same API as the real assembly. I won't go down that road again, as it was very manual and time consuming to turn that tool's output into something I could compile. But it did the job.
– Darryl
Nov 28 '18 at 20:29