Desktop Bridge app with PushNotificationChannel cannot find file 'System.Runtime.WindowsRuntime' - c#

I'm trying to allow a Desktop Bridge application to register for WNS notifications from an Azure Notification Hub, but when I actually use the UWP APIs it throws
`System.IO.FileNotFoundException: 'Could not load file or assembly 'System.Runtime.WindowsRuntime, Version=4.0.10.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.'
with an inner exception of
FileNotFoundException: Could not load file or assembly 'System.Runtime.WindowsRuntime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.
I set up my solution following the Visual Studio packaging instructions. My package project has a target version of Fall Creators Update, minimum version of Anniversary Update, and I associated it with a Windows Dev Center project for WNS support. All my .NET Framework projects are targeting v4.6.2. If I don't call any UWP APIs, the packaged application runs perfectly.
All the WNS code is in a single Class Library project, and that project is referenced by my desktop application (which is added to the package project's Applications). The class library has references for all six files in Microsoft's tutorial, with Copy Local = False for the three .winmd files:
the three DLLs from C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5
C:\Program Files (x86)\Windows Kits\10\UnionMetadata\Facade\Windows.winmd
C:\Program Files (x86)\Windows Kits\10\References\10.0.16299.0\Windows.Foundation.UniversalApiContract\5.0.0.0\Windows.Foundation.UniversalApiContract.winmd
C:\Program Files (x86)\Windows Kits\10\References\10.0.16299.0\Windows.Foundation.FoundationContract\3.0.0.0\Windows.Foundation.FoundationContract.winmd
The actual push notification function is inside an async method:
public namespace WnsClassLibrary
{
public class WnsChannelService
{
private PushNotificationChannel _channel;
public async Task CreateChannel()
{
_channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();
}
}
}
When the desktop application starts it tries to call CreateChannel() as an unawaited async method, and that's when the exception is thrown - as far as I can tell, it doesn't even actually make it inside the method.
Does anyone know why this happens or how I fix it? I tried setting the packaging project's minimum version to Fall Creators Update as suggested in UWP application: Could not load file or assembly 'System.Runtime.WindowsRuntime, Version=4.0.14.0, but I still get the same exception.

It looks like the problem might not actually be in Desktop Bridge or the UWP API references, but just a misconfigured assembly binding redirect.
While trying to get the exception to show up in a smaller solution, I found
<configuration>
<!--[unrelated configuration data...]-->
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Runtime.WindowsRuntime" publicKeyToken="b77a5c561934e089" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.0.10.0" newVersion="4.0.10.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
in the app.config files for both the desktop app and the WNS class library. Deleting that <runtime> element makes everything run fine, and copy/pasting it into my reproduction project makes the System.IO.FileNotFoundException start showing up.
I can't figure out what added that assembly binding redirect or make it happen again, but the desktop app was originally .Net 4.5 and took plenty of experimentation to migrate to .Net 4.6.2, update all the Nuget packages, and implement Desktop Bridge. My best guess is that something may have triggered a Nuget automatic configurator along the way?

Related

Web publish can't find Microsoft.Build.Framework

I'm using VS2017 with an ASP.NET project that I've inherited from another developer. I have the publish functionality set up to publish to a folder. This has all been working great until now.
The previous developer used EntityFramework, though all of the references were broken when I got the project, so I had to piece together what version. I'm using 6.2.0 currently and everything works fine. He apparently was using the automatic migration functionality. I've continued using this, but have had a couple situations where I had to enable data loss. I really don't want to do this, so the suggested path is to enable migrations and add the actual migrations. I'm not new to OR Mappers, but I am new to EF, so migrations are pretty new to me. In fact, it's been an uphill battle just to get things to work the way the docs say they are supposed to (see this thread)
So, now I am to the point of having my initial migration data. It seemed like the next step is to get this released to our dev server and then to our production server. So, being that I've used the publish functionality many times before with this project, I figured it would just work. Well, that's not the case now due to the changes I did to get EF migrations working.
The publish goes until it does this:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v / -p
C:\Users\Dan\Documents\Source\Repos\web-
app\WebApp\obj\Release\AspnetCompileMerge\Source -u
C:\Users\Dan\Documents\Source\Repos\web-
app\WebApp\obj\Release\AspnetCompileMerge\TempBuildDir
/global.asax(1,0): Error ASPPARSE: Could not load file or assembly
'Microsoft.Build.Framework, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system
cannot find the file specified.
ASPNETCOMPILER(0,0): Error ASPRUNTIME: Could not load file or assembly
'Microsoft.Build.Framework, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system
cannot find the file specified.
The first thing that struck me as interesting is that in order to get migrations to work, I had to install Microsoft.Build.Framework 15 (specifically I installed 15.1.1012 using nuget and then tried updating that to the latest, which is now 15.8.166). Seemed like more than a coincidence that this is a different version of the same library that is in the errors.
I saw some mention of needing to edit devenv.exe.config to change relative paths to absolute (here), but this didn't help.
I verified in the GAC that 4.0.0.0 is there. Apparently so is 14.0.0.0. From what I understand, installed versions that are less than 15 should be in the GAC.
I made sure Microsoft.Build.Framework was added (via nuget) to both my web app project as well as the project that has the EF context and migrations. The version 15 of Microsoft.Build.Framework was listed in both projects as a reference and was automatically set to Copy Local.
I tried changing the version referenced in my web app to 4.0.0.0, which initially had Copy Local set to false. Didn't help. Changed the 4.0.0.0 reference to Copy Local. This time, I'm met with a single error of:
Could not load file or assembly 'Microsoft.Build.Framework,
Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one
of its dependencies. The located assembly's manifest definition does not
match the assembly reference. (Exception from HRESULT: 0x80131040)
Now, my thought was since it looks like multiple versions are involved, maybe it should be taken care of with a binding redirect. I rarely have to deal with binding redirects, so I'm not much of an expert, but I did look at the web.config and it appears something (I'm assuming Nuget install of Microsoft.Build.Framework 15) had already entered the following:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-15.1.0.0" newVersion="15.1.0.0" />
</dependentAssembly>
So, considering that 4.0.0.0 is in the GAC and considering there's a redirect that I believe would redirect any 4.0.0.0 reference to 15.1.0.0, why would I get errors about not being able to find 4.0.0.0? Is there something I'm missing? I assume this must be related to something aspnet_compiler.exe is doing on a publish, since I can build and test the app fine on my development machine.
I had the exact same issue as described by OP.
Problem was solved by installing Microsoft Build Tools 2015
For me issue happened after moving from VS 2015 to VS 2017. However, I have heard few people reporting the same when a project created in VS 2015 is attempted to be published in VS 2017.
It's a Microsoft package issue, Microsoft seems to phase out support of older Nuget versions. This solution worked for me. Issue disappeared and now builds successfully.
In your Azure Build Pipeline > NuGet tool installer step, change Version of NuGet.exe to install to a newer version, like 5.4.0.
Check Nuget's latest ReleasedAndBlessed version at https://dist.nuget.org/tools.json.
In my case removing bindingRedirect from web.config and then installing latest nuget for Microsoft.Build.Framework worked like a charm.
Like the OP, I have a reference to Microsoft.Build.Framework v15 and I found that simply ensuring there are no assembly redirects for the Microsoft.Build.Framework assembly in the web.config allows my deployments to work. Having a redirect breaks deployments because we do the ASPNETCOMPILE stage to ensure views syntax is correct and the build breaks there with the OP's error message.
Unfortunately, Visual Studio 20XX loves to silently re-add an assembly redirect for it to my web.config with every nuget operation, and I have to remove it every stinking time, usually after a failed build reminds me:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-15.1.0.0" newVersion="15.1.0.0" />
</dependentAssembly>
My issue was uber specific but might help someone:
I was using Reflection to do some operations dynamically, and for that I was loading assemblies like this:
var types = AppDomain.CurrentDomain.GetAssemblies()
.SelectMany(s => s.GetTypes())
.Where(p => (typeof(IMandatorId).IsAssignableFrom(p) || typeof(INullableMandatorId).IsAssignableFrom(p))
&& typeof(IEntityModel).IsAssignableFrom(p))
.ToList();
However the GetTypes() method would fail for a specific assembly, which in my case was linked to a specific nuget package. I removed the package and stuff started working again.
For those interested the package was:
Microsoft.VisualStudio.Web.CodeGeneration
and problems started appearing after I upgraded all packages to .net 6

Could not load file or assembly Microsoft.Extensions.DependencyInjection.Abstractions, Version=1.1.0.0

After update to the new package Microsoft.EntityFrameworkCore.SqlServer 1.1.2 I got error when try to create DBContext:
System.IO.FileLoadException occurred HResult=0x80131040
Message=Could not load file or assembly
'Microsoft.Extensions.DependencyInjection.Abstractions,
Version=1.1.0.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) Source=Microsoft.EntityFrameworkCore StackTrace: at
Microsoft.EntityFrameworkCore.DbContext..ctor(DbContextOptions
options) at
Services.Infrastructure.Data.SqlServerDbContext..ctor(DatabaseOptions
databaseOptions) in
C:\src\backend\Packages\Services.Infrastructure\Data\SqlServerDbContext.cs:line
16 at
Translations.Api.Data.TranslationsDbContext..ctor(DatabaseOptions
databaseOptions) in
C:\src\backend\Modules\Translations\Translations.Api\Data\TranslationsDbContext.cs:line
16
My base DbContext
public class SqlServerDbContext : DbContext
{
private readonly DatabaseOptions _databaseOptions;
protected SqlServerDbContext(DatabaseOptions databaseOptions)
{
if (string.IsNullOrEmpty(databaseOptions.ConnectionString))
throw new Exception("Database connection string is missed.");
_databaseOptions = databaseOptions;
}
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer(_databaseOptions.ConnectionString);
}
}
Database options that I use
public class DatabaseOptions
{
public string ConnectionString { get; set; }
}
Place where I create instance of context
var dbOptions = new DatabaseOptions { ConnectionString = _connectionString };
DbContext = (TContext) Activator.CreateInstance(typeof(TContext), dbOptions);
// where TContext is derived class from SqlServerDbContext
All my packages are updated. Visual Studio 2017 15.2 (26430.6). Before upgrade to 1.1.2 everything works fine. Please help to solve the problem.
Since you're using the project in a .net framework library, there's an issue with auto-generated binding redirects (might be resolved in the upcoming 15.3 update / 2.0 .net core CLI). To work around it, add this in your cpsroj file (preferably before any <Import> element for a .targets file if present):
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
This should force MSBuild to create / update a YourProject.dll.config file containing the necessary binding redirects.
If you're working with Azure Functions in .NET Core this will work
If you're not using the .net framework library, but the .net core library, the accepted solution will not work because "you shouldn't be setting the property AutoGenerateBindingRedirects on a netcoreapp project as binding redirects aren't even a thing in netcoreapp, they are only a concept in .NET Framework" (source: https://github.com/microsoft/ApplicationInsights-dotnet/issues/1699#issuecomment-592693436).
Try this:
Uninstall Microsoft.Extensions.DependencyInjection.Abstractions
Uninstall Microsoft.Extensions.DependencyInjection
Although this seems like a radical solution, it works because the library is already indirectly installed through Microsoft.Azure.Functions.Extensions:
Important: Do not try to solve this issue by upgrading .NET Core from 3.1 to 5.0. Azure functions are still not supported in .NET 5.0. A patch is coming in early 2021:
https://github.com/Azure/azure-functions-host/issues/6674#issuecomment-712596112
EDIT: Azure functions are now supported in .NET Core (unless you're using durable entities, in that case you'll have to wait for .NET 6.0):
Today (10/3/2021), we announced support for running production .NET 5 apps on Azure Functions.
https://techcommunity.microsoft.com/t5/apps-on-azure/net-on-azure-functions-roadmap/ba-p/2197916
I Googled my exception below, and it brought me to this stakoverflow post.
System.IO.FileNotFoundException: 'Could not load file or assembly
'Microsoft.Extensions.OptionsModel, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=adb9793829ddae60' or one of its dependencies. The
system cannot find the file specified.'
I had the relevant Binding Redirects but if I Delete all bin/obj folders it worked fine afterwards.
This is an old thread but I had a similar same issue after I updated my Azure function from dotnet core version 3 to 3.1.
Error message: Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=3.1.9.0
In this case you need to update the Azure function version to 'v3' in .proj file.
I've been getting a similar issue using Azure functions 3.0.13
I kept getting the error System.IO.FileNotFoundException: 'Could not load file or assembly 'Microsoft.Extensions.Options, Version=6.0.0.0
I added a direct reference to the package via NuGet and then had to add this to my project.csproj file to make everything work. I can't take credit for this fix. I found it somewhere else a while ago, but I can't recall from where.
<PropertyGroup>
<_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>
</PropertyGroup>
I was having this problem. But the packet was Microsoft.Extensions.Primitives.
In my case I installed it in my Project and in my Project test from nuget. Maybe could help someone.
For me, what did it was to downgrade all the packages support .Net Standard to 2.2.0 from 3.x.x
i guess the 3.x packages relevant to a different version of .Net standard which does not support ,net framework.
It is a cracy thing, but for me what really worked was upating all packages that begins with Microsoft, since I updated my project to run over .Net 4.7.2, Then I just right click on Solution and Clean and Build again.
If Luis Gouveia solution doesn't work for you, try downgrading other dependencies included in the project. There are some compatibility issues with .NET standard.
Ref: https://github.com/Azure/Azure-Functions/issues/1729
I had same problem and finally fixed with below solution
Install "System.ComponentModel.Annotations" version 4.4.1 in a temporary project to get the file of "System.ComponentModel.Annotations.dll", then copy this file to your real project and then change your project reference to point this file instead of the original NuGet path
Then in your web.config add below code that redirec
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<publisherPolicy apply="no" />
<dependentAssembly>
<assemblyIdentity name="System.ComponentModel.Annotations" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="4.2.1.0" />
</dependentAssembly>
</assemblyBinding>
I was working on my simple .Net 5.0 Console app and while modifying my project's namespace the "auto-installation" added only the Microsoft.Extensions.DependencyInjection.Abstraction not the package nuget Microsoft.Extensions.DependencyInjection
It took me a while to realise that...
Here some solves :
1-I updated my packages from NuGet to latest version and working 100%.
2- make these editing in config :
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
</PropertyGroup>
3-Delete all bin and objct folders then clean solution and finally run , hope this will be work .
I had the same problem with a .Net Framework website that included an assembly using EFCore 3.1.22. I resolved the problem by putting the assembly redirects in the web.config.

Newtonsoft.Json reference complaining on Azure Functions

I'm running an Azure Functions, called SmsWebhook. It calls a method in an external assembly, AzureFunctionsSample.Services.dll that has a reference to Newtonsoft.Json 8.0.3
The details of my Run.csx looks like:
#r "AzureFunctionsSample.Services.dll"
using System.Net;
using AzureFunctionsSample.Services
public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)
{
...
}
Within the Run() method above, I create an instance and call a method in the instance. However, whenever I call that method, I receive the following error:
2016-05-19T13:41:45 Welcome, you are now connected to log-streaming service.
2016-05-19T13:41:46.878 Function started (Id=64fccf0c-d0ef-45ef-ac1c-7736adc94566)
2016-05-19T13:41:46.878 C# HTTP trigger function processed a request. RequestUri=https://ase-dev-fn-demo.azurewebsites.net/api/smswebhook
2016-05-19T13:41:46.878 Function completed (Failure, Id=64fccf0c-d0ef-45ef-ac1c-7736adc94566)
2016-05-19T13:41:46.894 Exception while executing function: Functions.SmsWebhook. Microsoft.Azure.WebJobs.Script: One or more errors occurred. AzureFunctionsSample.Services: Could not load file or assembly 'Newtonsoft.Json, Version=8.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040).
I manually added the same version of Newtonsoft.Json.dll under the bin directory, but still got the same error. Why is it complaining at the Newtonsoft.Json.dll file?
If I move all the logics within the external assembly into the Run.csx, it won't complain, by the way.
Json.Net can be simply reference adding this line at the top of your Run.csx file :
#r "Newtonsoft.Json"
See this article if you want to know which assemblies are automatically added by the Azure Functions hosting environment:
Azure Functions C# developer reference
Otherwise, if you want to use a specific version of Json.Net, you should probably add a reference to Json.Net using nuget package:
How can I use NuGet packages in my Azure Functions?
So you need to add a Project.json file that look like this:
{
"frameworks": {
"net46":{
"dependencies": {
"Newtonsoft.Json": "8.0.3"
}
}
}
}
If your external dependency references Newtonsoft.Json without using a nuget package, you can have a look at this post that explains how to upload your binaries:
How do I use external assemblies with Microsoft Azure Function Apps?
#JustInChronicles, I'm adding this here as an answer for reference, but the expected behavior should be that indirect dependencies of private assemblies are resolved from your bin folder, as expected.
I put together the following test to reproduce your scenario:
Created a simple class library with a simple type that uses Json.NET to serialize an object and return the JSON string. This assembly references Json.NET 8.0.3. The result includes the Json.NET assembly version it is using
Created a function that references that type only with a #r "DependencyWithJsonRef.dll" and returns the result produced by the method mentioned above
Deployed DependencyWithJsonRef.dll and Newtonsoft.Json.dll (8.0.3) to my function's bin folder
Invoking the function produces the expected result.
Here is the function, for reference:
#r "DependencyWithJsonRef.dll"
using System.Net;
public static string Run(HttpRequestMessage req, TraceWriter log)
{
var myType = new DependencyWithJsonRef.TestType();
return myType.GetFromJson();
}
As you can see, no explicit reference to indirect dependencies (Json.NET) required.
This is the output I get:
{
"Prop1":"Test",
"Prop2":1,
"AssemblyName": "Newtonsoft.Json, Version=8.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed"
}
Quick note: One thing you may want to check, particularly if you've updated that dependency while developing your function is that assembly resultion results were not cached. A sure way to make sure you're starting with a clean slate is to (after you deploy your function and assemblies) go to Kudu and kill the non-scm w3wp process to see if that helps. I'd be curious to know if that does the trick as there are a few things we can to to improve this if it does.
After some trial-and-error approach. I found what the issue was here.
#FabioCavalcante gave me a hint using a file-based reference,
#r "Newtonsoft.Json.dll"
It didn't work actually. I've copied those four files to Azure Functions' bin directory:
AzureFunctionsSample.Services.dll
AzureFunctionsSample.Services.pdb
Newtonsoft.Json.dll
Newtonsoft.Json.xml
It still gave me the same error, even though I did the file-based reference. Then, I found another file, AzureFunctionsSample.Services.dll.config that actually defines assembly binding redirects like:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
After I copied this config file to the Azure Functions' bin directory, it worked!
Lessons Learnt
Use the file-based reference for Newtonsoft.Json, #r "Newtonsoft.Json.dll", if your external assembly also has a reference to it.
Make sure that the assembly binding redirect configuration exists in Azure Functions' bin directory.
Correct me, if I'm still wrong.
Cheers,

How can I get my Web API app to run again after upgrading to MVC 5 and Web API 2?

I upgraded my Web API app to the funkelnagelneu versions using this guidance:
http://www.asp.net/mvc/tutorials/mvc-5/how-to-upgrade-an-aspnet-mvc-4-and-web-api-project-to-aspnet-mvc-5-and-web-api-2
However, after going through the steps (it seems all this should be automated, anyway), I tried to run it and got, "A project with an Output Type of Class Library cannot be started directly"
What in Sam Hills Brothers Coffee is going on here? Who said this was a class library?
So I opened Project > Properties, and changed it (it was marked as "Class Library" for some reason - it either wasn't yesterday, or was and worked fine) to an Output Type of "Windows Application" ("Console Application" and "Class Library" being the only other options).
Now it won't compile, complaining: "Program 'c:\Platypus_Server_WebAPI\PlatypusServerWebAPI\PlatypusServerWebAPI\obj\Debug\PlatypusServerWebAPI.exe' does not contain a static 'Main' method suitable for an entry point..."
How can I get my Web API app back up and running in view of this quandary?
UPDATE
Looking in packages.config, two entries seem chin-scratch-worthy:
<package id="Microsoft.AspNet.Providers" version="1.2" targetFramework="net40" />
<package id="Microsoft.Web.Infrastructure" version="1.0.0.0" targetFramework="net40" />
All the others target net451. Could this be the problem? Should I remove these packages?
UPDATE 2
I tried to uninstall the Microsoft.Web.Infrastructure package (its description leads me to believe I don't need it; also, it has no dependencies) via the NuGet package manager, but it tells me, "NuGet failed to install or uninstall the selected package in the following project(s). [mine]"
UPDATE 3
I went through the steps in again, and found that I had missed one step. I had to change this entry in the Application web.config File :
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
(from "4.0.0.0" to "5.0.0.0")
...but I still get the same result - it rebuilds/compiles, but won't run, with "A project with an Output Type of Class Library cannot be started directly"
UPDATE 4
Thinking about the err msg, that it can't directly open a class library, I thought, "Sure you can't/won't -- this is a web app, not a project. So I followed a hunch, closed the project, and reopened it as a website (instead of reopening a project).
That has gotten me further, at least; now I see a YSOD:
Could not load file or assembly 'System.Web.WebPages.Razor, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
UPDATE 5
Note: The project is now (after being opened as a web site) named "localhost_48614"
And...there is no longer a "References" folder...?!?!?
As to that YSOD I'm getting, the official instructions (http://www.asp.net/mvc/tutorials/mvc-5/how-to-upgrade-an-aspnet-mvc-4-and-web-api-project-to-aspnet-mvc-5-and-web-api-2) said to do this, and I quote:
"Update all elements that contain “System.Web.WebPages.Razor” from version “2.0.0.0” to
version“3.0.0.0”."
UPDATE 6
When I select Tools > Library Package Manager > Manage NuGet Packages for Solution now, I get, "Operation failed. Unable to locate the solution directory. Please ensure that the solution has been saved."
So I save it, and it saves it with this funky new name (C:\Users\clay\Documents\Visual Studio 2013\Projects\localhost_48614\localhost_48614.sln)
I get the Yellow Strip of Enlightenment across the top of the NuGet Package Manager telling
me, "Some NuGet packages are missing from this solution. Click to restore from your online
package sources."
I do (click the "Restore" button, that is), and it downloads the missing packages ... I end up with the 30 packages.
I try to run the app/site again, and ... the erstwhile YSOD becomes a compilation error:
The pre-application start initialization method Start on type System.Web.Mvc.PreApplicationStartCode threw an exception with the following error message: Could not load file or assembly 'System.Web.WebPages.Razor, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified..
Argghhhh!!! (and it's not even talk-like-a-pirate day).
UPDATE 7
I'm still curious about why Humpty Dumpty fell down and broke his crown (so to speak), but I finally threw in the towel and created a new project, copying-and-pasting code - and it works fine (VS 2013 and Web API, with REST methods called from a VS 2008, .NET 3.5 client app).
In the last step on the migration guide did you delete only the MVC4 Project Guid that is specified? I had the same problem as you and when I retraced my steps realised that I had deleted all three of the Guids within in my .csproj file. I restored the other Guids within this element and the solution now recognises it as a MVC application and now works OK. So the line now reads:
<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
Hope that helps
I recently ran into this problem, but it was a simple fix. I have multiple projects in my solutions (including several shared PCLs) and when I unloaded the project to change the ProjectTypeGuids, it set a PCL as the default. Right-clicking over my web service project and setting it back to the default startup project fixed it and everything is working.

Why this instance creation of reqpro40.applicationclass fails?

I am trying to open a ReqPro project from c# class code. The steps followed are:
Add reference to ReqPro.dll (the extensibility COM dll)
Create a type of ReqPro40.Application and have an instance of ReqPro40.ApplicationClass like:
ReqPro40.Application appReqPro = new ApplicationClass();
ReqPro40.Project prjReqPro;
prjReqPro = appReqPro.OpenProject(#"D:\MyReqPro\MyReqPro.rqs", ReqPro40.enumOpenProjectOptions.eOpenProjOpt_RQSFile, "admin", "admin", ReqPro40.enumProjectFlags.eProjFlag_Normal, ReqPro40.enumRelatedProjectOptions.eRelatedProjOption_ConnectNone);
The code compiles well, but when run (I wrote a simple Unit test), it fails saying "Could not load file or assembly 'Interop.ReqPro40, Version=1.10.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.":"Interop.ReqPro40, Version=1.10.0.0, Culture=neutral, PublicKeyToken=null".
Update1:
I tried it on my laptop, and it worked fine. I have ReqPro installed on my laptop. But it does not work on the server (Windows 2008 Enterprise). I connect to the server using remote connection. Any clue?
Update for bounty
I shall expect some working code with steps to recreate.
Please check on the server that the ReqPro.dll is in the root folder, sometimes the referenced dll's dont copy to the bin folder. You can also specify a "Probing" element in your app.config file to specify subfolders that the CLR can search to locate a referenced assembly if it cannot find the assembly.
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schmas-AWorks-cam:asm.v1">
<probling privatePath="bin\Ordersbin;Extbin"/>
</assemblyBinding>
</runtime>
</configuration>
Update:
If you arn't already I would suggest you use a Setup Project to Install your Project, this will make sure any 3rd party dlls, automatically get copied to the root folder were the application is installed.

Categories