So you created an ASP.NET application, hit a 404 Not Found error, and now you want to show something else other than the ugly default ASP.NET / IIS error pages, right? Well, sit back, because it’s rather annoying to setup properly. I strongly suggest reading the details that encouraged me to write this article. While that article definitely provides a majority of the setup required to make sure all cases and edge cases are handled when errors occur, there are some things that I had to do in order to make it all work properly.
Create a .html file and .aspx file for each error you want to handle. For example, 404.html and 404.aspx.
In the .aspx page, add this line below the “<%@ Page %>” directive where “xxx” is the error code you are handling such as 404 or 500.
In web.config, add this to your system.web section where each <error> section relates to whatever codes you are handling.
There are a ton of domain name registrars and hosts out there. Finding specific instructions to match the two together is something a bit of a challenge. To make things tougher, instructions aren’t always updated when user interfaces and processes are changed in the tools provided by these services. Hopefully, this article will provide simple instructions.
Log in to your Azure account and go to the management portal.
Your website must be set to “Shared”, “Basic” or “Standard” tiers in order to use custom domains.
If you want to eventually setup SSL on your custom domain, you will need to set the website to “Basic” or “Standard” tier.
Navigate to the dashboard of the Azure Website you are working with.
In the bottom toolbar, click “Manage Domains”.
Make note of the IP address listed at the bottom of the popup.
Log in to your Namecheap account.
Under “account information”, click to view your domains.
On the left sidebar, click “Your Domains”.
Click the domain you want to connect with Azure from the middle section.
On the left sidebar, click “All Host Records”.
Copy the IP address from step 4 to the IP Address / URL of the root host name “@”. Change that record type to “A Record”.
Copy the “xxx.azurewebsites.net” domain name to the IP Address / URL of the host name “www” where “xxx” is your website name. Change that record type to “CNAME”.
Under the subdomains section, add “awverify” and “awverify.www” subdomains. Set both IP Address / URL to awverify.xxx.azurewebsites.net where “xxx” is your website name. Change those record types to “CNAME”.
Save your changes. Wait until the DNS records propogate. Sometimes this takes awhile (over 24 hours). In my case, it took about an hour.
Go back to your Azure dashboard, add the domain and any subdomains to the popup from step 4. For example, “xxx.com” and “www.xxx.com” where “xxx” is your domain name.
As of Visual Studio 2013 Update 1, the ASP.NET MVC 5 templates with Authentication enabled will create a project that contains a class named ApplicationDbContext. This is the Entity Framework DbContext that is used by the ASP.NET Identity libraries to manage user records.
You’ll notice that it inherits from IdentityDbContext with a generic type of ApplicationUser. The base DbContext handles whatever is needed by the ASP.NET Identity libraries, and the ApplicationUser is the model that describes the authenticated user. If you’re like me, and you don’t want to create a ton of separate DbContext classes for different repositories, you can just mash it all together into ApplicationDbContext like so.
At a glance, it seems weird that a DbContext which is inherited from a very specific library contains other non-related DbSet objects, but it gets the job done. If you’re more into separation of concerns and don’t want a huge explosion of fluent API in a single class, look into creating separate DbContext classes as appropriate. Just remember that you need to maintain a connection string per DbContext in your web.config.… Read more
I have recently been playing around with ASP.NET MVC 5 via Visual Studio 2013 and the new ASP.NET Identity libraries. While the project templates mostly help you get to where you need to go when starting a brand new application, upgrading from the first Identity package (1.0) to the latest stable (2.0) wasn’t quite as smooth as I expected. For reference, Visual Studio 2013 Update 1 project templates use the 1.0 version of the ASP.NET Identity libraries. Visual Studio 2013 Update 2 RC (at the time of this writing), uses the 2.0 version.
By default, the project templates will set you up with a database schema that is accessible via EntityFramework and Code First. Since the templates utilize Code First, you will need to manage database migrations. And that’s where the trouble came in when upgrading from 1.0 to 2.0. The database schema changed (and will require code migrations) as a result of upgrading since the library supports new features like email confirmation, phone numbers, new primary keys, new indexes, and more. Attempting to run the application after simply upgrading all the libraries through NuGet gave me this essay of an error:
The model backing the ‘ApplicationDbContext’ context has changed since the database was created. This could have happened because the model used by ASP.NET Identity Framework has changed or the model being used in your application has changed. To resolve this issue, you need to update your database. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=301867). Before you update your database using Code First Migrations, please disable the schema consistency check for ASP.NET Identity by setting throwIfV1Schema = false in the constructor of your ApplicationDbContext in your application.
public ApplicationDbContext() : base(“ApplicationServices”, throwIfV1Schema:false)
Fortunately, the error message itself and a blog post gets you a good portion closer to finishing the upgrade process. By changing the constructor of ApplicationDbContext to pass in false to its base class for throwIfV1Schema, you can avoid this exception and force your way through the migration steps. So, in brief:
Open the Package Manager Console
If you haven’t for this project, type Enable-Migrations to allow code migrations to be used in your project
Type Add-Migration IdentityUpdate to create a migration script so the database schema can be brought up to speed to match the new model that was updated as a result of moving from 1.0 to 2.0. Note that the name of the migration can be anything.
Step 3 should fail if you have the same scenario as I did. You’ll probably see this error (which isn’t mentioned in the above linked blog post):
System.Data.Entity.Core.MetadataException: Schema specified is not valid. Errors:
(0,0) : error 0004: Could not load file or assembly ‘Microsoft.AspNet.Identity.EntityFramework, Version=184.108.40.206, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
You may have noticed that this post is about two months late. Time flies, doesn’t it? The previous post on an introduction to web services and how they work with ASP.NET provided you with a cursory glance. This post will provide you will how to implement a very basic web service both on the server side for consumption and the client side for use in an application.
Visual Studio 2005 or 2008
Basic knowledge of C#
Basic knowledge of ASP.NET Web Services
Step 1 – Create the ASP.NET Web Service
Visual Studio –> File –> New –> Project… –> Visual C# –> Web –> ASP.NET Web Service Application
Once the web service application project is created, notice that a templated web service was also created (Service1.asmx). The only section of this template to be worried about at the moment is the HelloWorld method marked with the [WebMethod] attribute. Marking methods as a [WebMethod] identifies that they will be used by an external caller through XML SOAP communication and are required to be exposed by the web service WSDL described in the previous post.
Make sure the HelloWorld method looks exactly like below.
That is literally all it takes to expose a web service method to the world! Press F5 to begin debugging this application in a local web server and continue to Step 2.
Step 2 – Utilize the Exposed Web Service Methods
One thing to note is that because web services are implemented via XML, any application that can properly serialize commands into the correct format as described by the web service WSDL has the ability to utilize web services. That said, the following section will be written using a simple C# console application.
Visual Studio –> File –> New –> Project… –> Visual C# –> Windows –> Console Application
Like library references, you need to add a reference to the URL path of the hosted web service. In the case of this article, the web service is hosted locally in the previous step.
In the main project of the solution explorer, right click Web References –> Add New Web Reference…
In the URL textbox, copy and paste the URL found in your browser that popped up from Step 1 when you pressed F5 to debug.
Press the Go button to the right of the URL textbox to search for any exposed methods at the URL provided.
When found, enter a name for the Web reference in the bottom right (I named it localhost.)
Press add reference to allow Visual Studio to create classes that allow consumption of the web service.
Add the following code to the Main method. Make sure you change “localhost” to whatever you called your web reference and change Service1 to the name of your exposed web service class.
NOTE: Microsoft no longer suggests using this method of web services, but it is useful knowledge if you are supporting legacy systems or are still required to implement these features for business purposes. This method of web service is still useful for internal operations that do not require high security.
Below is an overview image of common web service architectures. It’s easiest to think of web services at “web methods” contained within a “web library” that contains methods to be executed on a server. The strength of this approach is that all communication is done in a standard XML format, regardless of the platforms communicating. This allows for brand new systems to communicate with extremely legacy systems, assuming that each system can properly implement a valid SOAP request and response according to the WSDL contract.
Client: Any application that requires consumption of whatever methods the web service is exposing. Web Server: A process that hosts the web services for consumption. Broker: Provides the definition of the web services being exposed. SOAP: XML formatted request and results containing data according to the WSDL (see below.) WSDL: Definition language describing which method to execute, what parameters the method requires, what data types the parameters are, what results will be returned from the web service, and what data type to expect back from the web service.
A common SOAP request with a body but no header. Note that the method being executed is defined in the <m:GetStockPrice> tag and the parameters passed are described in the <m:StockName> tag.
A common SOAP response with a body but no header. Note that the response being returned is defined in the <m:GetStockPriceResponse> tag and the return value is described in the <m:StockNamResponsee> tag.