I am referencing Microsoft.Web.Administration 7.0.0 in my web application. Will it cause problems if my application is hosted in IIS 8.5? Has anyone come across any issues?
No it should not cause any trouble, actually make sure you reference 7.0.0.0 and that should be fine.
What people usually experience problems is when referencing 7.9.0.0 which ships with IIS Express causing lots of confusion and failures.
7.0.0.0 is the same version that ships with Windows 8 and 8.1 so you are all good.
Related
I maintain a .Net Framework 4.0 application (yes, I know) that depends on Mathnet.Numerics 3.11. Recently I started getting DllNotFoundException, saying that I lack MathNet.Numerics.CUDA.dll, when I call either Matrix<T>.Solve(Vector) or DenseMatrix.QR(). I reverted to older versions and found the problem persists. This is crippling for the application, and I'm really hoping to find out what I can do to make it work again. (Separately, I do have a project underway to rewrite the application in .Net 6, but that will not be done soon.)
I did find this GitHub issue which is not encouraging.
Is there a .Net Framework 4.0 version of MathNet.Numerics.CUDA.dll available somewhere? That would probably be the simplest solution, although I suspect it may be hardware dependent.
Just upgrade MathNet.Numerics to 3.20.2 (the latest release within major version 3) and the problem goes away. It appears that the implementation was changed to package the native BLAS providers within the main DLL rather than requiring a separate DLL for each one.
We have built an .NET application on ASP.NET core RC1 (release candidate 1) and deployed it on Windows Azure in an Web App container. By August the 2'nd the application stopped working over night. We found out it was caused by the fact that Microsoft stopped supporting RC1 (and RC2 for that matter) by that date.
The strange thing is that by today the application started working again without any change from our side.
Can anyone explain that behavior? I don't feel very comfortable with these kind of changes in the container environments.
NB: I should add that the error we saw in the log files was this one:
MissingMethodException: Method not found: 'Newtonsoft.Json.JsonSerializerSettings Microsoft.AspNet.Mvc.MvcJsonOptions.get_SerializerSettings()'
I can explain what happened: a version of Json.NET v6.0.4 was mistakenly added to the GAC. Due to the way Json.NET is versioned, apps that had a different 6.x version in their bin folder ended up loading the one in the GAC. Your RC1 app probably has v6.0.7, and broke because v6.0.4 was missing APIs.
This assembly is not supposed to be in the GAC at all, so when we realized the issue, we removed it, which is when your app started working again. Apologies for the downtime.
That being said, you really should move away from RC1, which is not officially supported.
I'm exploring Core MVC 1.0.
Is it possible to use Azure nuget packages I've been using in the past in previous Web API projects? For example, I've been using Microsoft.Azure.Mobile.Server.Notifications which gives me extension methods on HttpConfiguration that I can use in my controllers like:
var pushClient = Configuration.GetPushClient();
But I understand HttpConfiguration no longer exists.
Is there any way to use Azure packages like this with MVC controllers, or should I just be waiting until they release versions that target .net core? If so, are they even working on this? I can find anything anywhere.
Technically you can work with ASP.NET Core packages targetting the Full Framework too. We have several apps that are targetting netcoreapp and others targetting net461 due to Azure packages, but both use ASP.NET Core packages. Of course, this is valid if your environment has the Full Framework (Azure App Service does).
You can see how both the netcoreapp and net46 versions go related to NetStandard here.
To achieve this, remove the Microsoft.NETCore.App from the dependencies and change netcoreapp1.0 to net461 on your frameworks declaration.
When the NetCore-compatible packages go live, just reverse the change and your app will keep working.
With regard to the Mobile Apps Server SDK support for ASP.NET Core, the work is on our backlog, but we don't have a timeline to share. This is partly because some of the dependencies (such as Asp.NET OData and OData) don't yet support ASP.NET Core.
In the meantime, you could try #matias-quaranta's answer for how to use both together.
After I updated VS2015 yesterday and I cannot run my project (singla page app) anymore... Visual Studio says: Unable to connect to IIS express
I am using Solution DNX SDK version: 1.0.0-beta5
And my project.json is:
My references:
So everything should be ok ??
What am I doing wrong ?
BR
You have to understand that direct IIS hosting is no longer supported (and probably never will be again)! This is a decision by the ASP.Net team at Microsoft to completely concentrate on the kestrel server which is anyway required for Mac/Linux/Docker. By concentrating on one server the quality rises for everyone. Like Node, Kestrel recommends to use a reverse proxy in front of it. For that you can use your IIS/nginx/Apache.
I would urgently recommend you setup your project with RC1 and change to kestrel with HTTPPlatformHandler (in VS2015 Update 1 that works transparently with IIS Express for you). Beta5 is very outdated for many things.
It might be possible that your project could take a few hours before being able to run again.
First, you skipped beta6, beta7, beta8 and we are now at RC1.
Check which runtime you can use in Visual Studio and make sure you run with the latest one.
Once this is done, ensure that all your dependencies branded beta5 are renamed to the proper version that is in your Visual Studio. Some packages may have been removed, classes moved and many other things.
Check here for breaking changes:
Changes in beta6
Changes in beta7
Changes in beta8
Changes in rc1
I have a WPF application that targets framework v4.0 and uses async BCL. It seems that installing only .net framework v4.0 on fresh W7 OS is not enough, since as it seems, there was a bug which was corrected with later update. For example, installing update v4.0.3 solves the problem with using async BCL on framework v4.0.
My concern is this: On my developer machine (W8.1) I do not have this update installed (at least it is not registered in windows registry, nor under the windows updates). Still, my application is working just fine, which means that the update is somehow installed through some other method.
The question: how can I know that application that uses async BCL will work correctly on client's OS? Currently, when I install the application (wix 3.8), I check if .net 4.0 is installed, and I check if KB2600211 (4.0.3) is installed (by searching adequate registry keys). If not, I install them, but I am wondering if searching for KB2600211 is the right approach? Is there some other way to make sure that app will work correctly?
On your Windows 8.1 you have .NET 4.5.1 which is an in-place update for .NET 4.5 which is an in-place update for .NET 4.0. That means you no longer have plain .NET 4.0 (.NET 4.0.x, for that matter).
I recommend you to always test on the target environments. It can be as simple as having a VM.