I have a winform application that is meant to call an api to login and do other things.
When I run the api (.net core 2.2) on visual studio, and try to consume it from the WinsForm, it works fine. I later published the api and hosted it on IIS. It works fine when I launch it but the WinsForm won't work with the link I got from it (localhost/powerapi/login). It doesn't give an error, just doesn't work. I tried Fiddler with it(using the link from the IIS), it worked perfectly. Why is it not working with the WinsForm??
Please help.
UPDATE
I debugged again and found this error. It actually tries to call the API but it gets an error 500: Internal Server Error. I tried it on fiddler and got same error too. This is the screenshot of the error from visual studio
What i mean by "it works well" is that the api works well when i launch it from IIS into the browser(so as to get its link which is passed into "url" in the screenshot). And by IIS i mean local machine.
Also, the winform and the api on the same server because I'm currently running them on my pc.
Related
I have implemented Microsoft authentication using IIS Express and everything worked as expected (like the one from https://learn.microsoft.com/en-us/aspnet/core/security/authentication/social/microsoft-logins?view=aspnetcore-5.0).
However after I publish it to IIS, when a user tries to access the application, instead of the Microsoft login page, I get a page with the message
No webpage was found for the web address: <redirecturl>?code=...
I should mention that there is no other way to login. Only the Microsoft one has to be supported.
After further investigation I found out from where the problem was.
The server was protected and the IIS did not have access to the internet and a proxy was required. Hence the reason on IIS Express was working on the development machine but on the server IIS did not.
I have two application, both running on the same Windows machine. One application is IdentityServer4, and the other is my own web application (Server side Blazor app).
Both web apps are build with .NET Core 3.1.
When I navigate to my web app, I first get redirected to my IdentityServer4 app. I login, and after that I get redirected back to my web app.
The login was successful, because there are no errors in the logs of IdentitServer. Also, I see a certain claim value on my Blazor webpage. I display this claim through CascadingAuthenticationState in my Blazor page. Through that path everything works fine.
But, whenever I try to get the logged in user through HttpContext in my "code behind" files, I get a Null reference back. For example:
public UserService(IHttpContextAccessor httpContextAccessor)
{
// HttpClient is NULL...
var httpCtx = _httpContextAccessor.HttpClient;
}
The strange thing is, that it all works fine when I run my application locally in Visual Studio. When I debug in Visual Studio I see that the HttpContext is set with all my user data.
But, for some reason HttpContext is NULL when I run the app from IIS.
How can I solve this issue?
If the HttpContext null-reference exception happens after deployment to Azure App Services or IIS, you might have forgotten to enable WebSockets.
Here is the deal:
If the app runs on Windows with IIS: WebSockets must be enabled.
See the IIS/IIS Express support section.
It seems that this is a prerequisite that you have to follow. I only recently discovered this myself after dealing with the same issue and deciding to publish my app to Azure from within Visual Studio. After I did so, Visual Studio gave me a nice warning telling me to enable WebSockets protocol on the Azure App Service.
To enable websockets in azure app service. Open app service in azure portal -> configuration -> general settings -> websockets on or off. Described here
I've just upgraded an ASP.NET Core 1.1 web application to 2.0 and tested without issue locally. However, when the site is deployed to Azure a POST request that worked locally results in a 404 (I guess this could be the same for all POST requests, but I'm unable to log-in due to the issue).
Any ideas why this might fail to be working when deployed to Azure but working perfectly when run through IIS Express locally?
I deleted the original deployment slot on Azure and re-created as initially deploying over the slot mixed old 1.1 DLL's with the newer 2.0 DLL's and prevented the site working at all.
Seems I was caught out by poor handling of errors by my web application. I'd assumed that app.UseExceptionHandler("/Error") (I default my HomeController to not require the leading "Home" for /Home/Error) in Startup.cs would redirect to an error page, but for me it is not.
My underlying issue was a database connection error that caused the POST controller method to fail. I was caught out by the response returning a 404 rather than an error status.
I will need to investigate how error handling works in more detail for ASP.NET Core it seems.
I have a WCF service with webHttpBinding binding that works fine in Visual Studio 2010 / local IIS. The service has only one POST method that my separate web app project invokes via .NET's HttpWebRequest object. JSON is used for request and response. Request and response contain objects translated into and from JSON by DataContractJsonSerializer.
Once I deploy the service to a different Windows Server 2008 R2 machine on the same network, it generates "400 Bad Request" in response to the exact same calling code that works fine locally. By "calling code" I mean my web app running in Visual Studio.
No problems viewing the .svc file via a browser.
The request is less than one kB so it doesn't seem like size is an issue. Just in case I also tweaked the service's Web.config to allow for larger requests but that hasn't helped.
Resolved this shortly after posting question. Should clear things up.
My Cisco RV220W got confused. It wouldn't route the request properly, but the nature of what exactly it was doing and why the behavior was intermittent is beyond me. Rebooting it solved my problem.
Has anyone been able to get the MVC mini profiler working on IIS 6? I've set up the profiler in my application and it works perfectly in Visual Studio, IIS Express and IIS 7.5 but when I put the exact same application onto IIS 6 it won't work.
The problem seems to be around loading /mini-profiler-includes.js, I just get a 404 response. I've checked the route table and the correct routes have been registered by the profiler but apart from that I'm not sure what else to try.
On IIS 7, ASP.NET by default runs in integrated mode so the ASP.NET runtime will handle all requests, however on IIS 6 ASP.NET only handles extensions explicitly listed in the mappings section.
When the request comes in for /mini-profiler-includes.js IIS sees the .js and tries to serve the static file but as the file is "generated" by ASP.NET the handler never gets hit and a 404 error is returned.
In order to fix this you need to add a wildcard mapping to IIS so all requests get handed to ASP.NET. This blog post has a good walkthrough of the process.