I'm attempting to build a single page application using AngularJS on the client side and asp.net with Web API on the backend. I've been utilizing a complex client side build pipeline using Grunt. Long story short, this tool provides me a dist folder which contains all of my scripts/styles etc and is minified, uglified and all that good stuff.
At this point, I have no need for the server side MVC pipeline when it comes to URL routing and view rendering. I've placed the dist package at siteroot/Content/dist. Ultimately, my goal is to statically serve the files located there and leave the rest of the application intact. However, I've found no way to be able to do this. I'm forced to navigate to mysite.com/content/dist in order to actually see my application. I discovered virtual applications and directories and have attempted to remap the application at / to site\wwwroot\Content\dist. This has the intended effect in that now navigating to the root of my site serves the HTML files I'm looking for, however it simultaneously seems to break all of my Web API endpoints as it appears that the application is running out of a different path entirely.
Is there a way that I can have the best of both worlds? I want my API endpoints to exist as they do now but simply serve my site statically out of \Content\dist
You can use the StaticFiles middleware and set your dist folder as the root. I have an example how to set this up in a console application, but all you would need in an existing web app is to have a Startup class to configure in the middleware.
Related
I am about to convert my Winforms applications to an ASP.NET Web Application. The only question I have is the following:
My Winforms application connects to a server via TCP/IP connection (TCPClient), and handles all requests and commands through my own custom protocols (Strings sent that are validated server side and sent back to client)
Can I keep this same Server to handle the requests from my ASP.Net Web Application (I plan on using the same protocol)?
Will there be anything I have to change within the server? How different is migrating a Winforms application to an ASP.Net application?
Do you suggest I use WebForms or MVC?
Well, we might be confusing things here some what.
You have a asp.net application. Then the question is:
asp.net webforms application
or
asp.net webform web site
While both above are similar?
Well, in the first case, a web application means that you compile your code BEFORE web deploy, and for the most part this site is to be considered the WHOLE site (the web config file is in root etc.). And any external assemblies etc. are linked at compile (or publish time). And you are as a general rule NOT EDITING and design and working against the actual web site files. In other words, the folder that holds your project CAN NOT JUST be dragged say to a web server folder and it will work.
And of course this allows you to write custom handlers for pdf files or whatever.
So you can add + hook into the http handlers.
And of course this also allows you to build say a custom logon (authentication provider).
So, you can think of a web application more like a WHOLE application - just like say all the truckloads of source files that you have for a desktop application. You THEN compile this whole big thing, and you compile down to that .exe (or .dll).
You THEN must web publish the whole thing as a application to the web server.
so this is the whole site. Things like custom logon providers, http handlers, and even trapping the Session() start can be done.
And When you web publish, then you get a standard web site, and folders and all of the SOURCE vb.net (or c#) files are removed. Just like compiling down and deploying any desktop application - the source code and files are REMOVED. Needless to say, this approach is "common" to developers coming from a desktop environment.
So no sub-sites really can be done with this model. You are hooking DIRECTLY into the IIS web server.
A web site?
That is ONLY a set of folders that you can have the IIS site work against. In fact one could argue that AFTER you publish a web application, you get "mostly" the SAME thing as a web site.
But this model with any ease cobble up a web site with say 5 pages and JUST deploy that to your local web hosting? Nope!!! - can't do that!
The reason of course is you NOT dealing with ready made web site layouts and files. You HAVE to compile the whole mess into a application.
So like deploying an desktop application you are deploying a WHOLE system.
Now, if you going to have a site with say user logons, passwords and write a custom authenticaiton provider that IIS will respect and use? Again a web site can't do that.
So again you need a code system that supports logon hooks, and lets you control what those people can see and do. So for a line of business application? Well that quite much going to be a whole system - and thus you need control of logons, a master page(s) etc.
So the root, the config files, how they EVEN logon to your site? Everything must be just right and that config setup and file is the BASE SITE configuration for the web server. You can change authnetical providers - include custom http handles etc.
So this is a whole custom site here. And as noted, this is publish type operations.
However, asp.net for a long time ALSO supports what is called a web site.
So when the web started? Well, you just dumped web pages into some folders - maybe some hyper links to jump around. But a LOT of developers started out working this way. And because you can DIRECT edit the files and save them back to the site? Then no real concept of a application compile or even a web publish exists in this context. It just files sitting in a web ready format and a simple set of folders.
So a asp.net web site = just folders and files - no publish.
Now for one small change, no question that a web site is nice. And BETTER is that you can say take a set of folders and just DROP them into a existing web site - your not really publishing anything, so like the old days, you just edit and copy files to the web server folders and they work. This of course common fair html files.
But IIS does support using aspx pages (files) this way also!
Since this is just SOME folders with web pages? Then you can create and build say a bunch of different folders - each having their own cute little mini-web site. And this means that publishing to your cheap $8 per month asp.net hosting is possbile. You don't need a full IIS server and the ability to manage the IIS server system. All you EVER do is just copy files to the web site. Nothing more, nothing less. As a result, you don't have use of Session() start, and even the logon events are not under your control (unless of course you rolled your own and don't use IIS security.
With simple files and folders? Then your $8 hosting site can be used.
However, all if not most low cost simple hosting sites don't support asp.net applications.
So you can think of a web publish as replacing your base web application system the hosting provider gives to you. it also why you do NOT get use of the full ASP.net and IIS configuration options for the web site (your web provider controls and has that!!!).
One huge benefit of web sites is ease of change. As noted, you can point VS to directly edit even on the live web site files!!! There is really not concept of publishing - you just editing files and saving them to the web site folder. And this is really nice for a small change - the web site will re-compile the code for you, and for a large site, you can make a change to one wee bit of code behind and the web page - just copy that page and code to the site and you are DONE!!!
With a web application? you are doing a full-re compile, re-publish to the site for ANY and all changes. (well, ok, you could sneak in and say edit/change some markup on web page, but for the most part anything that messes with controls on a page would and could very easy break the compiled .dll's that are driving that page.
do you suggest I use WebForms or MVC?
That is a huge deal. MVC does not even have a visual designer for your web pages (you can only see and write markup).
And the whole MVC code model and whole event model is VERY different. So perhaps while a great idea to adopt MVC? (it is!!), it is darn near a whole re-write of your existing site - they work very different from asp.net webforms applications.
to a server via TCP/IP connection (TCPClient), and handles all requests and commands through my own custom protocols
If you mean custom http handlers? No, web sites don't' support this, you have to be creating a web site application. You can't by a simple act of placing some web pages on a web site have the lower level http handlers and network stuff change - you can only do that with a web application. Same goes for the authentication provider(s) you choose - simple web sites don't allow you to build your own custom providers (but you can roll your own logon system from scratch - but you not then enjoy even simple setups that automatic secure web pages based on their memberships in given security roles.
We are updating an ASP.NET Web Site project that uses ADFS 2.0 Authentication to use the one click "Publish Web Site" deployment process. We currently have three different FederationMetadata.xml files for each environment (dev, test, prod). How do we publish these files to each environment?
We use the web config transformation files for the web.config file. But I do not believe this can be used for xml files? From the searches that I have done I found two possible responses to this, neither seem very good. First one says to delete the FederationMetadata file and manually configure ADFS 2.0 (How do I change my WCF's FederationMetadata.xml file for various deployments?). We could do this but it seems like a step backwards. The second involves creating a dummy FederationMetadata file and populating it in the global.asax.cs file. (How to deploy asp.net web application to development team via TFS when setting up ADFS authentication). This approach seems very hackish and hardly the recommended approach.
Is there a recommended approach for this? Is there something obvious that I am not seeing? Any thoughts on this would be much appreciated!
If you indeed did manage to get the web.config correct then you can generate the metadata on the fly (per request). Same code for all environments. No need for the static file.
In telegram style just for the class names: For a Forms ASP.NET application it would be an HttpHandler (for MVC a controller). In the handler you must build a ApplicationServiceDescriptor, and use a MetadataSerializer to spit out the XML. Fill it with the info from FederatedAuthentication.WSFederationAuthenticationModule (which has obtained it from web.config).
I am trying to consume a Web API service from another ASP.NET classic project (actually it is a native JS and Html Web application).
How can I configure these these two separated projects to talk with each other, on VS2012?
The final result would be:
http://localhost:8080/api/products
will return a list of products (JSON) by routing to ProductsController located on the WebAPI project,
And
http://localhost:8080/index.html
will be routed to this page on the Second project - The native HTML/JS project.
How can I configure the logical to physical Directories in these two project?
Thanks!
As it turned out it's pretty simple.
All I had to do is configure these both projects to share the same port on the local IIS:
So for the native JS/HTML (my second project) I use:
And the second project (WEB-API project):
That is it!
Now the js can consume the Web-Api!
You just need a single project: ASP.NET Web API. I would put the index.html in the root and javascript files under scripts or js folder.
Normally static content such as js and html can be served directly by IIS in your ASP.NET Web API project. You need to make sure you add them to ignore rules in the startup:
RouteTable.Routes.IgnoreRoute("*.js");
RouteTable.Routes.IgnoreRoute("*.html");
When an AJAX call from the client side hits the server url, data of the type JSON, XML or CSV is exchanged with the browser.
What are the various alternatives for the server side end point for each of the following technologies for the AJAX url call (i.e. xmlhttprequestobj.open(TARGETURL))
1) ASP.NET (excluding AJAX Toolkit)
TARGETURL can be ASMX, WCF services, ASP .NET page serving the content
Is there any other way?
What is the standard way?
2.) For Java EE the target URL should be a servlet?
What is the standard here?
3.) How does it work for the LAMP stack and PHP?
What is the standard here?
For Java EE, Servlets can indeed be used. However, if you're looking at a more of less independent client application that does (AJAX) calls to server-side services, then JAX-RS is much more typical. JAX-RS' main function is to provide RESTFull web-services.
If you're looking at web pages that are more integrated with the server application, then JSF has first class support for processing AJAX calls as well. JSF's main function is to provide a component based MVC web framework.
The big difference is that with JAX-RS, you'll be making explicit calls using some URL pattern from your application and will manually process the data it returns (which can be in JSON or XML, but is rarely CSV).
With JSF the AJAX machinery is more a behind the scenes kind of thing for the average application developer. You put some component on your page, specify bindings to some backing bean, and at run-time AJAX interactions will take place.
You can use for example mod_rewrite in apache with php application and then your url can be for example yourapp.com/user/seahorse and this can be mapped by your application to whatever.php script. So url needn't be exactly mapped to some code unit.
If you are using LAMP, then you probably create new virtual host in apache config files, that is mapped to some domain (for example yourblog.com). And then if apache gets request to this domain, then it see to home directory of this app and try find appropriate script.
yourblog.com/user/whatever.php -> yourblog directory -> user directory - whatever.php
script.
Or you can put special file .htaccess to home directory of your app and in this file put some rewrite condition, for example all requests to index.php script.
I'm building an asp.net application that will be deployed on Azure. For the moment, I'm using regular asp.net: I'm building it in VS.
I have a web service that's in an asxm file MyService.asmx with a code behind file MyService.cs that calls a different class library called MyBigClass.cs that does most of the work.
If I want to prepare for a deployment on Azure in a few months and make that web service work in its own web role that I can scale based on usage load, should I put the classes that are in the MyBigClass.cs file into the MyService.cs file? The MyBigClass.cs file contains classes that are used for other parts of the application as well; should I remove these classes and only include the ones used by the web service?
Thanks.
Difficult to give a specific answer, and to be honest - I don't think the answer to this would be Windows-Azure-specific, but rather - this is simply a design best practice question, isn't it?
It comes down to how you will go about maintaining the application, and how you are going to manage versioning, but generally speaking - code that isn't shared does not need to get deployed to both roles, so either move it back with the 'parnet' solution (web app or service), or keep in a separate assembly which you will deploy with only the relevant role.
Code that is shared between the web app and service will exist in a shared assembly which you will deploy into both roles.
So you might end up with the following projects
A web site
An assembly supporting the web site
A Web service Service
An assembly supporting the web service
A shared assembly between the web site and web service
I hope this makes sense