So, I have been reworking an old WebForms site that our company has. In my initial efforts, I used Blazor which is SignalR based. This went well until I deployed the site to our servers that are behind a load balancer. After some research, I have come to the conclusion that unless the load balancer is configured to use sticky sessions, SignalR will not work.
https://learn.microsoft.com/en-us/aspnet/core/signalr/scale?view=aspnetcore-3.1
And, unfortunately, our IT department refuses to do so.
So, I am reconsidering using an MVC project with Razor pages. My question is, will a project of this sort use SignalR under the hood as well, thus putting me in the same predicament?
If there are any other gotchas that anyone with more experience could point out, that would be appreciated as well.
Related
I have already done a proof where I can include Node.JS within an ASP.NET MVC application.
Assume that I am going to use an external session provider like windows server appfabric Cache or memcache.
I have an application where there is a quite sophisticated assembly that we use to build middle tier objects that we then store in the session. The assembly and the objects it produces is our most valuable piece and I cannot justify rewriting this C# project into something this is more Node.JS friendly.
This data is stored in an external cache, and now the node.JS developers need access to that.
What techniques have you guys used in situations like this? I am pretty sure that I am going to have to have some sort of service interface provide by the asp.net side as it is the one that owns this system of record.
I am also looking for a green field option for new projects that allow both ASP.NET MVC and Node.Js work together well in a hybrid fashion anyway, so perhaps this could be solved by data being stored in a convention that works for both.
Thanks.
I wouldn't use ASP.NET session at all. Maybe a database would be a more interoperable approach. SQL Server or even NoSQL solution such as RavenDB might be a good choice.
The problem with ASP.NET out-of-proc session state providers is that they use non-interoperable serializers (such as BinaryFormatter or NetDataContractSerializer) so you cannot read the data back from NodeJs. There might even be differences in the serialization mechanism between the different versions of the .NET framework so even with 2 ASP.NET applications running on different versions of the framework it might be a challenge to share session data.
I am attempting to do some domain redirects on one of the sites on my server (Server 2003, IIS6), but the Extensionless URLs feature of .Net 4 keeps tacking on that eurl.axd/GUID before the redirect. I found some info on that here.
I would just disable this feature, as described here, but I am pretty sure this will impact an MVC .Net site I also have set up in IIS (because MVC uses extensionless URLs).
Can someone please assist me in finding other options? Is there a way to just remove the eurl.axd/GUID from the URL, via an IHttpModule? I haven't been able to find an example of anyone doing this or something similar.
Ok, I seem to have fixed things on my own. Originally I had both my websites set up in IIS under the same App Pool. I separated them into different app pools, made sure they were both set to .Net 4, and everything started working. Now when users are redirected from one domain to another, the eurl.axd/GUID does not get tacked on to the end of the URL.
I'm struggling to find a decent walkthrough for this issue, and was hoping that someone could shed some light on this... I've built an application using a ton of Unity and DI, and I need to pull a few components into a web site and run a WCF service now with them. host a WCF service for clients to connect to it instead of having it included as part of the main application (multi-user scenario where I'm hosting the database for them.)
I've searched and found several documents, but they seem to be focused on running a single service, instead of writing a framework to do the dirty work for me.
I'm wondering, as I've said in the topic, has anyone found "the difinitive guide" on doing this?
Doing a little more research, i did find a few things on how to get the dependency injection to work, where you are implementing/extending an instance provider, a Service Behavior, and a Service Host class... and then in your website, you build a ServiceHostFactory that does the wire-ups from the concrete methods to your interfaces. The only piece of the puzzle I have yet to discover is how you now use *.dlls that have a class which implements IModule, and have the site discover it on the fly.
Discovery on the fly sounds a lot like an extensibility/Add-In scenario. In that case, the Managed Extensibility Framework (MEF) might be a good fit for you.
Despite what many people think, it's also available for .NET 3.5.
I've seen several similar scenarios explained here but not my particular one. I wonder if someone could tell me which direction to go in?
I am developing two (and more later) MVC2 apps. There will also be another (thicker) client later on (WPF or Silverlight, TBD).
These all need to share the same authentication. For the MVC2 apps they (preferably) need to be single log on - ie if a user logs in to one MVC2 app, they should be authorised on the other, as long as the cookie hasn't timed out.
Forms authentication is to be used.
All the apps need to use common business functionality and perform db access via a common WCF Service App. It would be nice (I think) if the WCF is not publicly accessible (ie blocked behind FW). The thicker client could use an additional service layer to access the Common WCF App.
What this should look like is:
MVCApp1 -> WCFAppCommon
MVCApp2 -> WCFAppCommon
ThickClient -> WCFApp2 -> WCFAppCommon
Is it possible to carry out all the authentication/authorization in the WCFAppCommon?
Otherwise I think I'll have to repeat all the security logic in the MVCApps and WCFApp2, whereas, to me, it seems to sit naturally in WCFAppCommon. On the otherhand, it seems if I authenticate/authorize in WCFAppCommon, I wouldn't be able to use Forms Authentication.
Where I've seen possible solutions (that I haven't tried yet) they seem much more complex than Forms Authentication and a single DB.
Any help appreciated,
Phil
I thought I should come back to this with what I've learned (and re-learned).
First the re-learned lesson - don't become fixed on an architecture and then try and make everything else fit. I'm fixed on .Net, SQL Server, WCF, MVC2, EF4, and IIS7. Fixing in my mind how I want these to fit together is slighly dumb! Better to go out and look at what guidance exists.
Which brings me to what I learned - here's a link:
http://wcfsecurityguide.codeplex.com/
I discounted this article a couple of times because it's a bit dated. However, I'd say it's actually very relevant and if you're starting a project remotely concerned with securing services go take a look. Part IV had everything I needed.
We are using WCF Web Application hosting Reporting system (we are accessing it from Silverlight) and since it's using same machine keys as our MVC application - we can share cookie authentication as well.
Otherwise, you have to send authentication ticket (custom or not) to your WCF application.
We are getting ready to do a an initial deployment of an ASP.net MVC app on IIS 6 running on Windows Server 2003. We've been reading about performance issues involving the use of extenionless urls in MVC applications specifically in the case of removing the '.aspx' extension from the controller portion of the url.
Has anyone who has deployed an MVC app in the past experienced any performance degradation in this area? Was it noticeable, and was it worth it for having the cleaner URLs? Our application will rarely have to deal with more than 1000 or so concurrent users.
Edit: Thanks for all the responses, it's working quite well, although there are a few strange requests going through as some people mentioned, I think we can work around these using the suggestions mentioned here.
We recently deployed an app that received approx. 20 million page views over a 3 month period using the IIS 6 wildcard mapping setup and had no performance issues. We did host most of our images on a CDN, but other static content was served directly from the site.
For what it's worth, IIRC, the asp.net handler will pass requests for static file types back to IIS through a default handler for processing. The only practical performance hit is the time during that process that a worker thread is occupied identifying and transferring the request. In all but the most extreme scenarios, this is too trivial to matter.
As an extra note, we load tested the application I mentioned prior to going live and found that it could handle nearly 2000 static requests per second and around 700 requests per second for pages that involved database activity. The site was hosted on 4 IIS 6 servers behind a ZXTM load balancer with a 1GB internet pipe.
Here's a link with some good advice on the whole static file handling business:
http://msmvps.com/blogs/omar/archive/2008/06/30/deploy-asp-net-mvc-on-iis-6-solve-404-compression-and-performance-problems.aspx
The problem with not using extensions on IIS 6 is that you don't want static requests to go through the ASP.NET stack. If all of your static requests come from one (or two...) subfolder(s), you can exclude them. This should fix the performance issue.
Quoting from the linked post:
Now, to remove the wildcard map on the
/Content subdirectory, open a command
prompt, go to c:\Inetpub\AdminScripts,
and run:
adsutil.vbs SET /W3SVC/105364569/root/Content/ScriptMaps ""
… replacing 105364569 with the
“identifier” number of your
application. (Also, you could replace
“Content” with the path to any other
directory.)
We ran a fairly busy site with IIS6 wildcards on for extensionless URLs and although we never noticed much of a performance hit, we did have a little hack that worked quite well:
For all folders that contained only static files, like /css, /images, /scripts etc, in IIS we set them as their own application, and disabled the wildcard setting, which meant IIS handled the requests rather than routing through ASP.Net.
Url rewriting can help you to solve the problem. I've implemented solution allowing to deploy MVC application at any IIS version even when virtual hosting is used.
http://www.codeproject.com/KB/aspnet/iis-aspnet-url-rewriting.aspx
Instead of serving all the requests by ASP.NET, you could specify e.g. mvc as the extension (say index.mvc) and map that extension to aspnet_isapi.dll in IIS 6.
This means only known extenions will be processed by asp.net, others like static files stay the same as before i.e. served by IIS itself.