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;








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?










share|improve this question


























  • 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

















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?










share|improve this question


























  • 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













0












0








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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

















  • 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












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
);



);














draft saved

draft discarded
















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.




















draft saved

draft discarded















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Kamusi Yaliyomo Aina za kamusi | Muundo wa kamusi | Faida za kamusi | Dhima ya picha katika kamusi | Marejeo | Tazama pia | Viungo vya nje | UrambazajiKuhusu kamusiGo-SwahiliWiki-KamusiKamusi ya Kiswahili na Kiingerezakuihariri na kuongeza habari

SQL error code 1064 with creating Laravel foreign keysForeign key constraints: When to use ON UPDATE and ON DELETEDropping column with foreign key Laravel error: General error: 1025 Error on renameLaravel SQL Can't create tableLaravel Migration foreign key errorLaravel php artisan migrate:refresh giving a syntax errorSQLSTATE[42S01]: Base table or view already exists or Base table or view already exists: 1050 Tableerror in migrating laravel file to xampp serverSyntax error or access violation: 1064:syntax to use near 'unsigned not null, modelName varchar(191) not null, title varchar(191) not nLaravel cannot create new table field in mysqlLaravel 5.7:Last migration creates table but is not registered in the migration table

은진 송씨 목차 역사 본관 분파 인물 조선 왕실과의 인척 관계 집성촌 항렬자 인구 같이 보기 각주 둘러보기 메뉴은진 송씨세종실록 149권, 지리지 충청도 공주목 은진현