unbind BindAsLegacyV2Runtime - .net-4.0

So we have an application launcher which can (should) run new apps created in clickOnce and older apps that use a remoting type of logic
When trying to run the apps I received the following message
Cannot load assembly. Error details: System.IO.FileLoadException: Could not load
file or assembly 'program' or one of its dependencies. Operation is not
supported. (Exception from HRESULT: 0x80131515) File name:'program'
---> System.NotSupportedException: An attempt was made to load an assembly from
a network location which would have caused the assembly to be sandboxed in
previous versions of the .NET Framework. This release of the .NET Framework does
not enable CAS policy by default, so this load may be dangerous. If this load is
not intended to sandbox the assembly, please enable the loadFromRemoteSources
switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
Googling I found this piece of code which says update the app config
Loading blocked and network-hosted assemblies with .NET 4
That fix the older apps but now broke the newer apps
So then I found
Setting useLegacyV2RuntimeActivationPolicy At Runtime
And this "works" in that if I load a new app first, no issue, then I load an older app and it is ok, but then if I go to load a new app it stops working.
So either I need to know how to unbind BindAsLegacyV2Runtime when I am about to run new apps. Or I need a whole other approach?
Thanks

Adding
<runtime>
<loadFromRemoteSources enabled="true"/>
</runtime>
Fixed the issue for both types of application

Related

Kestrel fail: Can not load Microsoft.Extensions.Logging.Abstractions

I had a very simple Kestrel / ASP.NET Core project successfully deployed to my Windows 2008 R2 server.. (started with an empty Web project + IdentityServer4 nuget I was following this Getting Started page)
So, I could initially retrieve the 'discovery' JSON document.
Then, (per this guide) I added a couple of NuGet packages to it, some views/CSS, etc...
Microsoft.AspNetCore.Mvc -Version 1.1.0
Microsoft.ApsNetCore.StaticFiles -Version 1.1.0
The upgraded solution runs fine on my Win7 dev box, but, after redeploying.. Now I get the dreaded 502.5 error page. If I go into the server and try to "jump start" the executable via command line.. I can see this error:
Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Extensions.Logging.Abstractions, Version=1.1.1.0, Culture=neutral,PublicKeyToken=adb9793829ddae60' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) at Ross.Web.Applications.Identity.Program.Main(String[] args)
Where did I go wrong?
I can see the aforemetioned DLL, Microsoft.Extensions.Logging.Abstractions, published to the server's file system. I'm guessing I need to do a binding redirect or something, but, I'm too new to core to know how.
UPDATE
After upgrading my NuGet packages to the latest.. the error is similar, but now it can't find: Microsoft.AspNetCore.Hosting.Abstractions, Version=1.1.2.0
People that have multiple projects in solution, pay attention:
This is mainly because there are multiple projects in your solution, and the mentioned package is installed in both of them but with different versions.
Suppose that the exception is like the following:
Simply stop debugging and go to the Manage NuGet Packages for Solution and search for that package in the installed tab:
As you can see, I have that package in two projects with different versions, and that's the point! Simply update the lower version equal to the higher version and you're all set.
Ok, I had to clear out my server's directory.. and do a fresh redeploy.
I had seen other answers about deleteing the 'bin' but was confused, since core web deployments don't feature an actual /bin directory.
Now, I take that to mean, "Clear out the binaries.. wherever they may be"
This is a common issue when mixing 1.1.0 and 1.1.1 asp.net core dependencies.
The simplest solution is to update all dependencies to 1.1.1. If this isn't possible, then you will need to add a binding redirect to redirect the 1.1.1 dependencies to target 1.1.0 assemblies.
After you change these dependencies or add the binding redirects, clear out you /bin folder locally, and turn clean on your next build.

Could not load file or assembly 'System.Diagnostics.DiagnosticSource on ASP.Net Core migration from VS2015 to VS2017

I have a web in ASP.Net Core (4.6.1 framework) that uses Facebook and MS external login that I created with Visual Studio 2015 and opened in the new Visual Studio 2017 that came out yesterday. VS2017 made a few changes related to the csproj, project.json, etc files.
The site compiled and executed fine except for one part. If I did a Facebook or Microsoft external login, the site displayed this trap:
FileLoadException: Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
System.Net.Http.WinHttpHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
AggregateException: Unhandled remote failure.
Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler+<HandleRemoteCallbackAsync>d__6.MoveNext()
The url in the browser showed that it was attempting to return from the external login to the local (https://localhost:44321/signin-facebook?code=... or /signin-microsoft).
The version number of the System.Diagnostics.DiagnosticSource.dll (and System.Net.Http.dll) is 4.6.24705.1.
I started a new VS2017 project from scratch with Facebook and MS login added and it worked fine - getting me logged on without the trap. The dll's were the same versions.
Comparing the two csproj files showed differences but nothing obvious (nothing related to System dlls):
What solved it for me was to add a NuGet reference to System.Net.Http (version 4.3.1) to the newly migrated project.
https://www.nuget.org/packages/System.Net.Http/
The recommended answer did not resolve my issue. I was getting this error when trying to reference a .Net 4.6.2 lib in a .Net Core 2 project.
To resolve the issue I had to add the Microsoft.Windows.Compatibility nuget package.
Credit to: https://medium.com/#ans_ashkan/asp-net-core-and-windows-event-log-75770a80a666
In References 'System.Diagnostics.DiagnosticSource' not included in solution
On installing latest version "5.0.1" of 'System.Diagnostics.DiagnosticSource' in NUget solved my issue. Hope it will fix yours also.
I had the same issue and weirdly enough, problem resolved with updating Microsoft.ApplicationInsights versions. 2.20.0 is the version to go (for me). I don't know the connection between these packages but that's what happened.
People using .NET Core web applications monitored with Application Insights hosted in App Services facing this issue
This when .NET Core web application has a dependency on 'System.Diagnostics.DiagnosticSource%u2019 binary and has this binary file deployed to /wwwroot/ folder, which is rare.
Work Around: Please set previous version of monitoring extension by changing this app setting if you experience the above issue: ApplicationInsightsAgent_EXTENSIONVERSION=2.8.24
After doing this please restart the application.
Here is the source

Could not load file or assembly 'System.Web.Http.WebHost, Version=4.0.0.0, Culture=neutral,PublicKeyToken=31bf3856ad364e35'

In Visual Studio 2012 I created an ASP.NET MVC 4 project where the target framework is the .NET Framework 4.5. When I deployed my project to a web server it gave the following error:
Could not load file or assembly 'System.Web.Http.WebHost, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file
specified.
Description: An unhandled exception occurred during the execution of the current web request.
Please review the stack trace for more information about the error and where
it originated in the code.
Exception Details: System.IO.FileNotFoundException: Could not load file or
assembly 'System.Web.Http.WebHost, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies.
The system cannot find the file specified.
Source Error:
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.34237
I had the same issue today during deployment. I was able to fix it by marking the assembly to be copied to the deployment file.
In order to do this, in my Visual Studio project, select the System.Web.Http.Webhost assembly in your references and alter the 'Copy Local' property to True. I had to repeat this for a few other assemblies that were missing.
Thanks to this website for the tips - http://haacked.com/archive/2008/11/03/bin-deploy-aspnetmvc.aspx/
Check the bin folder of your deployed project. It should contain System.Web.Http.WebHost.dll.
If this dll is in this folder, check it version. If it isn't 4.0.0.0, then you should deploy version 4.0.0.0 or change your web config to use other version (not really good idea because of dependencies)
Try to reinstall Microsoft.AspNet.WebApi package. Open Package Manager Console and type:
Update-Package Microsoft.AspNet.WebApi -reinstall
Be careful, this command will remove all dependencies and you will have to install them manually.
I had this error with an old project that I was going back to do a bit of work on. It turns out the project wasn't actually using WebApi so I uninstalled Microsoft.AspNet.WebApi using NuGet. That solved the problem for me.
If I'd actually have needed WebApi I'm sure installing it again would have fixed the error too.
I ran into this today after setting up a new Team City Build Agent. The new agent didn't have MVC 4 installed, perhaps part of the problem. Fortunately, I found this article which lead me to the solution. In Team City, I just updated the Build Step for the Nuget Restore so that it doesn't use the local cache.
This works because the cache may have been established by build runners with different (MVC) frameworks installed already.
I know this is answered but I thought I'd add something.
Every time I set "copy local" to true on a file causing the error I'd publish it and just get another one. So I just selected all of the files under references and set them all to true. This fixed the issue for me.
Important: This error message can be caused because you are deploying a 4.5 project to a server that doesn't have 4.0 installed. Make sure you have the .NET Framework version installed in IIS for the project you need. Some of these DLLs by default won't copy up, because it uses the core project DLL normally. Check to make sure your production server has the .NET version you're going with. I experienced this myself with a 4.5 project on a 4.0 server.
Ensure ASP.NET MVC 4 is installed on your server. Check it in the following location -
C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 4

How do I stop Ninject for WebApi failing on "var kernel = new StandardKernel();"

I just installed Ninject.MVC5 into my solution (I have an MVC project and a WebApi project in there and I wanted Ninject for both).
Then I installed WebApiContrib.IoC.Ninject to build on the previous install so that I could use Ninject in the WebApi package.
Then I updated the packages (because NuGet showed updates to install - even though I had updated the packages directly prior to installing Ninject).
I tried running my WebApi project but it failed on var kernel = new StandardKernel(); in NinjectWebCommon.CreateKernel() with this error:
An exception of type 'System.IO.FileNotFoundException' occurred in Ninject.dll but was not handled in user code
Additional information: Could not load file or assembly 'System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
Having read several answers on here and contemplated certain relatively complex solutions I tried one more thing which I will share in the Answer in case it helps anyone else...
I removed WebApiContrib.IoC.Ninject from the WebApi project (via NuGet: Manage and then untick to remove) and then added it back.
Project runs and behaves as expected, and no updates are required after adding WebApiContrib.IoC.Ninject back in to WebApi project.
The update that NuGet identified as required overwrote/broke something that was fixed by this answer.
Add the package Microsoft.Aspnet.Mvc from Nuget.
Solved for me.
In my case, MVC4 for Framework 4.0 and Visual Studio 2017

XBAP uses unmanaged c++ COM server, Side by side deployment issue

I'm facing a the following situation:
I created a simple full trust XBAP application that refers to unmanaged c++ COM server (isolated).
After deployment I expect that XBAP application will discover the COM server dll that is placed in the same directory, but it is not.
I'm getting the following error:
Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {970599E0-2673-11D3-A8A8-00105AA943DF} failed due to the following error: 80040154.
at Generation888.Generation888.Simple(Int32 num1, Int32 num2)
I verified that the folder where the XBAP was deployed contains the DLL and XBAP manifest that contains proper CLSID
If I created a simple C# Windows Form application and refers to the same COM dll, it works fine.
My question is does XBAP support Side-by-Side mechanism.
Thanks
I'm not terribly familiar with XBAPs so these are some general suggestions.
If your XBAP is in fact being launched as a separate executable since it's fulltrust (what does taskmgr say?), try using the "sxstrace.exe" tool from an elevated command line on Windows Vista or later to determine whether the XBAP manifest is actually being interpreted by the system. It's possible that if you first tried your application without a manifest or changed the manifest, the system cached this old information and you'll need to clear this manifest-state cache by touching the timestamp of both the manifest and the executable.
It's also possible that your executable has an embedded manifest, which would mean that the external manifest is being ignored. To check this open the executable up in Visual Studio and see if it has an RT_MANIFEST resource of ID 1.