Using when main executable is not .NETUsing different versions of the same assembly in the same folderWhat is a smart pointer and when should I use one?How to enable assembly bind failure logging (Fusion) in .NETWhen should static_cast, dynamic_cast, const_cast and reinterpret_cast be used?When to use virtual destructors?Difference between decimal, float and double in .NET?How do I create and use a .NET metadata-only 'Reference Assembly'?How to reference 3rd party assemblies without copying them locally?.NET assembly binding redirection when new version become signed but previous notResolving/using multiple assembly versions from 3rd party dependenciesAvoid loading external references when registering a .Net assembly
Where does the expression "triple-A" come from?
I asked for a graduate student position from a professor. He replied "welcome". What does that mean?
How do I determine what is "magic" and "bearing magic" for Detect Magic?
Linear Programming with additional "if-then"/"Default to zero" constraints?
Random point on a sphere
Can a corpse possessed by a Dybbuk be turned via Turn Undead?
Why is Kirchoff's Second Law True?
What is a realistic time needed to get a properly trained army?
Telling my mother that I have anorexia without panicking her
Are scroll bars dead in 2019?
Will replacing a fake visa with a different fake visa cause me problems when applying for a legal study permit?
Why did it become so much more expensive to start a university?
Is there a real-world mythological counterpart to WoW's "kill your gods for power" theme?
Sol Ⅲ = Earth: What is the origin of this planetary naming scheme?
Uncovering the Accelerated Dragon opening
Why isn't `typename` required for a base class that is a nested type?
Were Roman public roads build by private companies?
Do I need 3 RGB channels for a spectrogram CNN?
Is there a reliable way to hide/convey a message in vocal expressions (speech, song,...)
What was the relationship between Einstein and Minkowski?
When was the earliest opportunity the Voyager crew had to return to the Alpha quadrant?
Can I disable a battery powered device by reversing half of its batteries?
Why would "an mule" be used instead of "a mule"?
Resume: How to quantify my contributions as a software engineer?
Using when main executable is not .NET
Using different versions of the same assembly in the same folderWhat is a smart pointer and when should I use one?How to enable assembly bind failure logging (Fusion) in .NETWhen should static_cast, dynamic_cast, const_cast and reinterpret_cast be used?When to use virtual destructors?Difference between decimal, float and double in .NET?How do I create and use a .NET metadata-only 'Reference Assembly'?How to reference 3rd party assemblies without copying them locally?.NET assembly binding redirection when new version become signed but previous notResolving/using multiple assembly versions from 3rd party dependenciesAvoid loading external references when registering a .Net assembly
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
For a while now I've been researching a safe and local way of allowing two different versions of the same assembly to be used by an application. There are several SO and online articles dealing with the issue, however there is a "gotcha" with every solution I read.
Let's imagine we have two 3rd party libraries (we have no control over) that use different versions of Newtonsoft
(using Newtonsoft
as an example, it can be any other dependency). We want each of the 3rd party libraries to use the Newtonsoft
version they were built against. Following are some of the solutions I came across (from here and here):
Using a single version
Not ideal and sometimes not possible if each 3rd party library can work only against a specific version of a dependency.
Use GAC
Don't really want to.
Use AssemblyResolve
Will solve the main issue, however is considered unsafe to manually load two versions of the same assembly ourselves (rather than letting the runtime handle such task).
Use <codebase>
This is the most promising solution. The way I understand it is that I'm letting the runtime handle loading different versions of the same assembly, and my assumption is that it will do so in a safer way than me manually using AssemblyResolve
. I just think of this as a LAC (Local Assembly Cache)™
. However, to my understanding putting this in the App.config
of a class library (rather than executable) will be completely ignored. Here is my situation:
My app is developed in C++
and consumes .NET
assemblies through C++/CLI
. The .NET
assemblies consumed are the ones that depend on 3rd party libraries, which themselves depend on different versions of the same assembly (i.e Newtonsoft
). So really my question is there a way to use <codebase>
when the main app/executable is developed with C++
? Is there a way to get <codebase>
to be used with a .NET
class library?
If <codebase>
cannot work when the main app is a C++
one, is my only option to install the latest version of the dependency (i.e Newtonsoft
), and pray that it is backward compatible, so that 3rd party libraries that depend on older versions can still consume the latest version at runtime?
EDIT
I have followed Hans's suggestion by placing the <codeBase>
in a config file that has the same name as the executable, which works fine. For example the config structure can be as follows:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="DependencyName" culture="neutral" publicKeyToken="DependencyPublishToken" />
<codeBase version="1.0.0.0" href="DependencyName1.0.0.0/DependencyName.dll"/>
<codeBase version="2.0.0.0" href="DependencyName2.0.0.0/DependencyName.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
The only think I'd like to confirm (cannot find an answer anywhere) is this as safe as putting the assemblies in GAC? For example, would doing it this way still lead to issues mentioned here, or would it be safe because we're letting the runtime handle everything, and ensuring we only do the above for strong named assemblies?
c++ .net assemblies multiple-versions
add a comment |
For a while now I've been researching a safe and local way of allowing two different versions of the same assembly to be used by an application. There are several SO and online articles dealing with the issue, however there is a "gotcha" with every solution I read.
Let's imagine we have two 3rd party libraries (we have no control over) that use different versions of Newtonsoft
(using Newtonsoft
as an example, it can be any other dependency). We want each of the 3rd party libraries to use the Newtonsoft
version they were built against. Following are some of the solutions I came across (from here and here):
Using a single version
Not ideal and sometimes not possible if each 3rd party library can work only against a specific version of a dependency.
Use GAC
Don't really want to.
Use AssemblyResolve
Will solve the main issue, however is considered unsafe to manually load two versions of the same assembly ourselves (rather than letting the runtime handle such task).
Use <codebase>
This is the most promising solution. The way I understand it is that I'm letting the runtime handle loading different versions of the same assembly, and my assumption is that it will do so in a safer way than me manually using AssemblyResolve
. I just think of this as a LAC (Local Assembly Cache)™
. However, to my understanding putting this in the App.config
of a class library (rather than executable) will be completely ignored. Here is my situation:
My app is developed in C++
and consumes .NET
assemblies through C++/CLI
. The .NET
assemblies consumed are the ones that depend on 3rd party libraries, which themselves depend on different versions of the same assembly (i.e Newtonsoft
). So really my question is there a way to use <codebase>
when the main app/executable is developed with C++
? Is there a way to get <codebase>
to be used with a .NET
class library?
If <codebase>
cannot work when the main app is a C++
one, is my only option to install the latest version of the dependency (i.e Newtonsoft
), and pray that it is backward compatible, so that 3rd party libraries that depend on older versions can still consume the latest version at runtime?
EDIT
I have followed Hans's suggestion by placing the <codeBase>
in a config file that has the same name as the executable, which works fine. For example the config structure can be as follows:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="DependencyName" culture="neutral" publicKeyToken="DependencyPublishToken" />
<codeBase version="1.0.0.0" href="DependencyName1.0.0.0/DependencyName.dll"/>
<codeBase version="2.0.0.0" href="DependencyName2.0.0.0/DependencyName.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
The only think I'd like to confirm (cannot find an answer anywhere) is this as safe as putting the assemblies in GAC? For example, would doing it this way still lead to issues mentioned here, or would it be safe because we're letting the runtime handle everything, and ensuring we only do the above for strong named assemblies?
c++ .net assemblies multiple-versions
An app.exe.config file works just fine when app.exe is a native C++ executable. No real idea how you'd want to leverage codebase, you'd consider a bindingRedirect to force the newer version of the DLL to get used consistently. Putting the two DLLs in the GAC is another way.
– Hans Passant
Mar 28 at 10:45
@HansPassant I was thinking of putting each different version of a dependency in a dedicated folder, and point each version to the relevant folder using <codeBase>. So if I have two different versions, there will be two different folders and two <codeBase> elements.
– Kakalokia
Mar 28 at 11:34
@HansPassant bindingRedirect has the same drawback as using a single version as the 3rd party library may only work against a specific version (i.e newer versions are not backward compatible).
– Kakalokia
Mar 28 at 11:35
add a comment |
For a while now I've been researching a safe and local way of allowing two different versions of the same assembly to be used by an application. There are several SO and online articles dealing with the issue, however there is a "gotcha" with every solution I read.
Let's imagine we have two 3rd party libraries (we have no control over) that use different versions of Newtonsoft
(using Newtonsoft
as an example, it can be any other dependency). We want each of the 3rd party libraries to use the Newtonsoft
version they were built against. Following are some of the solutions I came across (from here and here):
Using a single version
Not ideal and sometimes not possible if each 3rd party library can work only against a specific version of a dependency.
Use GAC
Don't really want to.
Use AssemblyResolve
Will solve the main issue, however is considered unsafe to manually load two versions of the same assembly ourselves (rather than letting the runtime handle such task).
Use <codebase>
This is the most promising solution. The way I understand it is that I'm letting the runtime handle loading different versions of the same assembly, and my assumption is that it will do so in a safer way than me manually using AssemblyResolve
. I just think of this as a LAC (Local Assembly Cache)™
. However, to my understanding putting this in the App.config
of a class library (rather than executable) will be completely ignored. Here is my situation:
My app is developed in C++
and consumes .NET
assemblies through C++/CLI
. The .NET
assemblies consumed are the ones that depend on 3rd party libraries, which themselves depend on different versions of the same assembly (i.e Newtonsoft
). So really my question is there a way to use <codebase>
when the main app/executable is developed with C++
? Is there a way to get <codebase>
to be used with a .NET
class library?
If <codebase>
cannot work when the main app is a C++
one, is my only option to install the latest version of the dependency (i.e Newtonsoft
), and pray that it is backward compatible, so that 3rd party libraries that depend on older versions can still consume the latest version at runtime?
EDIT
I have followed Hans's suggestion by placing the <codeBase>
in a config file that has the same name as the executable, which works fine. For example the config structure can be as follows:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="DependencyName" culture="neutral" publicKeyToken="DependencyPublishToken" />
<codeBase version="1.0.0.0" href="DependencyName1.0.0.0/DependencyName.dll"/>
<codeBase version="2.0.0.0" href="DependencyName2.0.0.0/DependencyName.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
The only think I'd like to confirm (cannot find an answer anywhere) is this as safe as putting the assemblies in GAC? For example, would doing it this way still lead to issues mentioned here, or would it be safe because we're letting the runtime handle everything, and ensuring we only do the above for strong named assemblies?
c++ .net assemblies multiple-versions
For a while now I've been researching a safe and local way of allowing two different versions of the same assembly to be used by an application. There are several SO and online articles dealing with the issue, however there is a "gotcha" with every solution I read.
Let's imagine we have two 3rd party libraries (we have no control over) that use different versions of Newtonsoft
(using Newtonsoft
as an example, it can be any other dependency). We want each of the 3rd party libraries to use the Newtonsoft
version they were built against. Following are some of the solutions I came across (from here and here):
Using a single version
Not ideal and sometimes not possible if each 3rd party library can work only against a specific version of a dependency.
Use GAC
Don't really want to.
Use AssemblyResolve
Will solve the main issue, however is considered unsafe to manually load two versions of the same assembly ourselves (rather than letting the runtime handle such task).
Use <codebase>
This is the most promising solution. The way I understand it is that I'm letting the runtime handle loading different versions of the same assembly, and my assumption is that it will do so in a safer way than me manually using AssemblyResolve
. I just think of this as a LAC (Local Assembly Cache)™
. However, to my understanding putting this in the App.config
of a class library (rather than executable) will be completely ignored. Here is my situation:
My app is developed in C++
and consumes .NET
assemblies through C++/CLI
. The .NET
assemblies consumed are the ones that depend on 3rd party libraries, which themselves depend on different versions of the same assembly (i.e Newtonsoft
). So really my question is there a way to use <codebase>
when the main app/executable is developed with C++
? Is there a way to get <codebase>
to be used with a .NET
class library?
If <codebase>
cannot work when the main app is a C++
one, is my only option to install the latest version of the dependency (i.e Newtonsoft
), and pray that it is backward compatible, so that 3rd party libraries that depend on older versions can still consume the latest version at runtime?
EDIT
I have followed Hans's suggestion by placing the <codeBase>
in a config file that has the same name as the executable, which works fine. For example the config structure can be as follows:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="DependencyName" culture="neutral" publicKeyToken="DependencyPublishToken" />
<codeBase version="1.0.0.0" href="DependencyName1.0.0.0/DependencyName.dll"/>
<codeBase version="2.0.0.0" href="DependencyName2.0.0.0/DependencyName.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
The only think I'd like to confirm (cannot find an answer anywhere) is this as safe as putting the assemblies in GAC? For example, would doing it this way still lead to issues mentioned here, or would it be safe because we're letting the runtime handle everything, and ensuring we only do the above for strong named assemblies?
c++ .net assemblies multiple-versions
c++ .net assemblies multiple-versions
edited Mar 28 at 13:29
Kakalokia
asked Mar 28 at 9:21
KakalokiaKakalokia
2,2132 gold badges15 silver badges34 bronze badges
2,2132 gold badges15 silver badges34 bronze badges
An app.exe.config file works just fine when app.exe is a native C++ executable. No real idea how you'd want to leverage codebase, you'd consider a bindingRedirect to force the newer version of the DLL to get used consistently. Putting the two DLLs in the GAC is another way.
– Hans Passant
Mar 28 at 10:45
@HansPassant I was thinking of putting each different version of a dependency in a dedicated folder, and point each version to the relevant folder using <codeBase>. So if I have two different versions, there will be two different folders and two <codeBase> elements.
– Kakalokia
Mar 28 at 11:34
@HansPassant bindingRedirect has the same drawback as using a single version as the 3rd party library may only work against a specific version (i.e newer versions are not backward compatible).
– Kakalokia
Mar 28 at 11:35
add a comment |
An app.exe.config file works just fine when app.exe is a native C++ executable. No real idea how you'd want to leverage codebase, you'd consider a bindingRedirect to force the newer version of the DLL to get used consistently. Putting the two DLLs in the GAC is another way.
– Hans Passant
Mar 28 at 10:45
@HansPassant I was thinking of putting each different version of a dependency in a dedicated folder, and point each version to the relevant folder using <codeBase>. So if I have two different versions, there will be two different folders and two <codeBase> elements.
– Kakalokia
Mar 28 at 11:34
@HansPassant bindingRedirect has the same drawback as using a single version as the 3rd party library may only work against a specific version (i.e newer versions are not backward compatible).
– Kakalokia
Mar 28 at 11:35
An app.exe.config file works just fine when app.exe is a native C++ executable. No real idea how you'd want to leverage codebase, you'd consider a bindingRedirect to force the newer version of the DLL to get used consistently. Putting the two DLLs in the GAC is another way.
– Hans Passant
Mar 28 at 10:45
An app.exe.config file works just fine when app.exe is a native C++ executable. No real idea how you'd want to leverage codebase, you'd consider a bindingRedirect to force the newer version of the DLL to get used consistently. Putting the two DLLs in the GAC is another way.
– Hans Passant
Mar 28 at 10:45
@HansPassant I was thinking of putting each different version of a dependency in a dedicated folder, and point each version to the relevant folder using <codeBase>. So if I have two different versions, there will be two different folders and two <codeBase> elements.
– Kakalokia
Mar 28 at 11:34
@HansPassant I was thinking of putting each different version of a dependency in a dedicated folder, and point each version to the relevant folder using <codeBase>. So if I have two different versions, there will be two different folders and two <codeBase> elements.
– Kakalokia
Mar 28 at 11:34
@HansPassant bindingRedirect has the same drawback as using a single version as the 3rd party library may only work against a specific version (i.e newer versions are not backward compatible).
– Kakalokia
Mar 28 at 11:35
@HansPassant bindingRedirect has the same drawback as using a single version as the 3rd party library may only work against a specific version (i.e newer versions are not backward compatible).
– Kakalokia
Mar 28 at 11:35
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/4.0/"u003ecc by-sa 4.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%2f55394005%2fusing-codebase-when-main-executable-is-not-net%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
Is this question similar to what you get asked at work? Learn more about asking and sharing private information with your coworkers using Stack Overflow for Teams.
Is this question similar to what you get asked at work? Learn more about asking and sharing private information with your coworkers using Stack Overflow for Teams.
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%2f55394005%2fusing-codebase-when-main-executable-is-not-net%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
An app.exe.config file works just fine when app.exe is a native C++ executable. No real idea how you'd want to leverage codebase, you'd consider a bindingRedirect to force the newer version of the DLL to get used consistently. Putting the two DLLs in the GAC is another way.
– Hans Passant
Mar 28 at 10:45
@HansPassant I was thinking of putting each different version of a dependency in a dedicated folder, and point each version to the relevant folder using <codeBase>. So if I have two different versions, there will be two different folders and two <codeBase> elements.
– Kakalokia
Mar 28 at 11:34
@HansPassant bindingRedirect has the same drawback as using a single version as the 3rd party library may only work against a specific version (i.e newer versions are not backward compatible).
– Kakalokia
Mar 28 at 11:35