assembly-binding-redirect

System wide bindingRedirect for F# 4.0.0.0 to 4.3.0.0

馋奶兔 提交于 2019-12-04 03:28:13
问题 I have some xUnit tests which are failing with the common Could not load file or assembly 'FSharp.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. To perform a machine-wide redirect, I added to the file C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="FSharp.Core"

Powershell - Assembly binding redirect NOT found in application configuration file

对着背影说爱祢 提交于 2019-12-04 00:18:46
问题 Got a problem here... I have got a Powershell CmdLet that works when running in 32-bit mode and fails in 64-bit mode. Question is what the cause is and how it can be fixed. Situation Powershell CmdLet that references 'OutlookHelper.Common.dll'. Newest version is 2.0.0.0 The CmdLet also uses logging and references 'Logging.dll'. Logging.dll also references 'OutlookHelper.Common.dll', only was compiled against version 1.0.0.0. How I made it work, this works partially Using an assembly binding

Can I tell bindingRedirect to always use the latest available version?

爷,独闯天下 提交于 2019-12-03 15:11:37
问题 Having an ASP.NET application there are several entries in the Web.Config file in this format: <dependentAssembly> <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="0.0.0.0-1.6.5135" newVersion="1.6.5135" /> </dependentAssembly> These libraries come as NuGet packages. Now every time I update my 20+ NuGet packages I do something like: One click to update all packages. Open the application in browser. See errors like this one. Open my Web

Could not load file or assembly System.Web.Http, Version=5.2.2.0

我只是一个虾纸丫 提交于 2019-12-03 14:56:41
问题 I've just uploaded a Asp.Net Web Api 2.2 project to production server and I got the error stated in the title. In my Web.config I already have this: <dependentAssembly> <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-5.2.2.0" newVersion="5.2.2.0" /> </dependentAssembly> The file does exist in the bin. What would cause this? All my Asp.Net Web API files are up to date and show 5.2.2 as the version. It works

Can I tell bindingRedirect to always use the latest available version?

主宰稳场 提交于 2019-12-03 05:49:31
Having an ASP.NET application there are several entries in the Web.Config file in this format: <dependentAssembly> <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="0.0.0.0-1.6.5135" newVersion="1.6.5135" /> </dependentAssembly> These libraries come as NuGet packages. Now every time I update my 20+ NuGet packages I do something like: One click to update all packages. Open the application in browser. See errors like this one . Open my Web.Config, find the binding redirect entry. Lookup the assemblies latest version. Modify my web.config. Update

Do binding redirects in app.config for class libraries do anything?

跟風遠走 提交于 2019-12-03 05:28:15
问题 The VS solutions I often work with consist of a single executable project (console app, web app) and many class library projects that are all referenced by the executable. When working with NuGet and installing packages, there's often an app.config file created for each project, usually containing nothing else than a list of binding redirects that consolidate versions of referenced assemblies. Sometimes there's some third-party library-specific content (like Entity Framework config section),

Could not load file or assembly System.Web.Http, Version=5.2.2.0

喜你入骨 提交于 2019-12-03 04:44:53
I've just uploaded a Asp.Net Web Api 2.2 project to production server and I got the error stated in the title. In my Web.config I already have this: <dependentAssembly> <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-5.2.2.0" newVersion="5.2.2.0" /> </dependentAssembly> The file does exist in the bin. What would cause this? All my Asp.Net Web API files are up to date and show 5.2.2 as the version. It works fine on my dev machine. Set Copy Local to true in the properties for the System.Web.Http and System.Web

Do binding redirects in app.config for class libraries do anything?

…衆ロ難τιáo~ 提交于 2019-12-02 18:46:00
The VS solutions I often work with consist of a single executable project (console app, web app) and many class library projects that are all referenced by the executable. When working with NuGet and installing packages, there's often an app.config file created for each project, usually containing nothing else than a list of binding redirects that consolidate versions of referenced assemblies. Sometimes there's some third-party library-specific content (like Entity Framework config section), but let's leave that aside for now. When I build the solution and use the binaries of the main

System wide bindingRedirect for F# 4.0.0.0 to 4.3.0.0

无人久伴 提交于 2019-12-01 17:23:21
I have some xUnit tests which are failing with the common Could not load file or assembly 'FSharp.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. To perform a machine-wide redirect, I added to the file C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/> <bindingRedirect oldVersion="4.0.0.0" newVersion="4.3

F# PowerPack Target Runtime

二次信任 提交于 2019-11-29 12:18:08
The pre-built binaries for the F# PowerPack are compiled against the .NET 2.0 runtime. If I have a .NET 4.0 project, is there any advantage to compiling the PowerPack source for the .NET 4 runtime? I used .NET 2.0 version of F# PowerPack in F# snippets web site , which is a .NET 4.0 ASP.NET project. The only disadvantage of not using 4.0 version was that I had to add configuration to load 4.0 version of FSharp.Core.dll when looking for 2.0 version (which is referenced by the 2.0 version of PowerPack). I had to add something like the following and then it worked just fine: <configuration> <!--