In VS 10 we use MSDeploy behind the scenes to deploy your entire web application along with all of its dependencies like IIS Settings, DB, web content etc to any destination server.

MSDeploy is a new technology specially designed to serve the purpose of deploying web applications seamlessly across IIS Servers. My hope is to give you a CONCEPTUAL high level overview to understand how web deployment with VS10 & MSDeploy really works.

In case of web deployment or replication across server farms what you really require is to take the web and its dependencies from one box to another. To further over simplify there is a source (your dev box) and there is a destination (your web server), the source needs to be replicated on to the destination and that is what we are trying to achieve (with of course a lot more details behind the scene :-)

MSDeploy uses this simple concept of taking the source and applying it on to the destination. Let us try to understand what all are possible sources:

Source:

- If you want to deploy the site you are developing on your dev box then now the site you are developing on the dev box becomes the source.
- If you have your web content stored in the source control and you have a build server which is set up for automatic deployment then the build server becomes the source.
- If you have a MSDeploy web package given to you by someone and you are trying to install it on your dev box then the web package becomes the source.

Destination:

- If you are deploying a web to a test server then the test server is the destination.
- If you are creating a web package out of your web site using MSDeploy then the web package becomes the destination.
- If you are deploying to your own dev box for testing purposes then in this case your dev box itself becomes the destination.

Well the concepts of source and destination are pretty simple but the reason why they are so interesting is because when you set up your deployment settings in Visual Studio then VS creates something that we call as Source Manifest and feeds to MSDeploy. Check out the figure below which gives you an idea of how VS 10 will produce your web package:



Source Manifest is a simple XML which instructs MSDeploy on what all Providers to invoke on the source machine. So what is a MSDeploy Provider?

A MSDeploy provider is a simple object which MSDeploy engine invokes to do two major CONCEPTUAL tasks:

1. On Source Machine to GET the right content from its place

e.g. if you had Database attached to your web then at source DB Provider will be called to pull out your data and schema and convert it into SQL Scripts which will then go into the web package.

2. On Destination Machine to PUT the right content in its place

e.g. if there were SQL scripts in your web package then at destination DB Provider will be called to run the SQL command and the SQL scripts to create and set up the database

MSDeploy comes with a lot of pre-built providers like:

- IIS Settings providers for IIS 5.1 (for XP), IIS 6.0 (for Win2K3) & IIS 7.0(for Vista & Win2K8)
- DB Provider for MS SQL Server
- GAC
- COM
- Registry
- etc etc

Based on your project settings Visual Studio creates a source manifest which is fed to MSDeploy to create package or deploy your web application. So on the source box below is how MSDeploy works:



Along with creating the source manifest, Visual Studio also creates destination manifest for you. Check the below diagram:



When you are ready to deploy then on the destination you can feed the web package and the destination manifest to MSDeploy to deploy your web site. In the destination manifest you can change the values like “IIS Application Name”, “DB connection strings” etc.



This is how you can use web packages on any machine with MSDeploy and by configuring your deployment options in the destination manifest you can go and and easily recreate your webs.

It is not possible for someone to come up with every possible provider that everyone needs so there will be an extensibility model by which you can write your own providers and register it with MSDeploy engine.

Visual Studio is also made extensible to allow you to hook into the packaging and publishing process to call your custom MSDeploy providers in the source manifest.

The most interesting pieces is that with IIS Manager and Visual Studio 2010 UI, you will not really need to know all these details, things will just work but I thought it is often interesting to know how things work behind the scenes.

I hope this conceptual overview helps you get the perspective on how web deployment with VS 2010 and MSDeploy will work!!

This is an error message that sometimes you might see when you published your site with WebDeploy. Yeah, we know WebDeploy sometimes is hard and not so easy as you think, but if you have problem with your current provider, you can consider our hosting plan. We support WebDeploy and we are Microsoft certified partner. Ok, let’s go to the problem:

“Error: An unsupported response was received. The response header ‘MSDeploy.Response’ was ” but ‘v1′ was expected.
Error: The remote server returned an error: (401) Unauthorized.”

This means that you do not have access. So, you need to create ticket to us and then we will set a username and password for your both your web deploy and remote IIS user.

Maybe you find another problem like this:

Error: The remote server returned an error: (503) Server Unavailable. Web Deploy may not be setup or running on that server. Please contact us in order to resolve the issue.

An error occurred when the request was processed on the remote computer.
The server experienced an issue processing the request. Contact the server administrator for more information.

This is the most common error we see and, unfortunately, it does not tell you much. What this means is that, usually, you have successfully connected to the server, however for some reason your deployment failed. Usually, this means that you are attempting to do something that you do not have access to do (such as deploying to the root directory – which you need full control permissions in order to do and this must be granted by us). Please check your settings and ensure that everything is correct. Also, if you do contact us, providing a screenshot of your deployment settings (Service URL, Site/Application and Username/Password) will assist us in troubleshooting your issue.

Lastly, I want to talk about the SetAcl deployment handler. Once you decide to publish to your root directory you can do some damage by removing the permissions from your files/folders if you aren’t careful. In order to fix this each file/folder must be reclaimed and the permissions reset, which is quite a bit of work and very time consuming for us.

SetAcl can be found in your WAP project file.

What is SetAcl? It’s a provider that lets you set permissions on file system objects. Typically, this involves setting permissions on a sub-folder of your application, such as App_Data.

Let’s say you run this command:

msdeploy.exe -verb:sync -source:setacl -dest:setacl="Default Web Site",setacluser=ApplicationPoolIdentity,setaclaccess=Read

This command will give the ApplicationPoolIdentity Read access to the App_Data folder. Before it does that, however, it will clear existing permissions on the folder for the identity. This makes sense, since setAcl has to set the correct permissions and the only way to do that is to clear existing permissions for the identity. For example, if the ApplicationPoolIdentity had Read,Execute permissions before, now it will just have Read permissions.

In order to disable it, you edit the .csproj file and set:

1. <IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination>

or do this from the command line:

2. msbuild.exe myproject.csproj /p:IncludeSetAclProviderOnDestination=False

Following the above instructions will allow you to safely deploy to the root directory.

Hope this article will help you if you find problem like above.

Xdebug is a very popular PHP extension that helps with debugging and profiling of PHP scripts by providing a lot of valuable debug information. Microsoft WebMatrix is a development tool for building web applications. When WebMatrix is used to build or modify a PHP-based web application the debugging tasks can be greatly simplified if Xdebug extension is used. This post explains how to install and use Xdebug extension with WebMatrix.

Step 1: Enable PHP in WebMatrix from the site “Settings” page:



Note that if you installed any of the PHP applications from the Application Gallery then PHP will be automatically enabled.

Step 2: Download the appropriate build of Xdebug extension from downloads page. If your site uses PHP 5.2 then download “5.2 VC6 Non-thread safe (32 bit)”. If your site uses PHP 5.3 then download “5.3 VC9 Non-thread safe (32 bit)”. Use 32 bit build even if your Windows OS is 64 bit.

Step 3: Install the extension by copying the downloaded file to the following locations:

-          For PHP 5.2 on Windows 64 bit:
C:\Program Files (x86)\IIS Express\PHP\v5.2\ext\

-          For PHP 5.2 on Windows 32 bit:
C:\Program Files\IIS Express\PHP\v5.2\ext\

-          For PHP 5.3 on Windows 64 bit:
C:\Program Files (x86)\IIS Express\PHP\v5.3\ext\

-          For PHP 5.3 on Windows 32 bit:
C:\Program Files\IIS Express\PHP\v5.3\ext\

Step 4: Open the php.ini file located in the PHP installation folder, e.g.
C:\Program Files\IIS Express\PHP\v5.2\php.ini and append the following at the end (make sure that the absolute path is correct for your version of PHP and Windows.):

[xdebug] 
zend_extension = C:\Program Files\iis express\PHP\v5.2\ext\php_xdebug-2.1.0-5.2-vc6-nts.dll

Step 5: Configure PHP to display errors by changing these PHP settings in php.ini file:

display_errors = On  
error_reporting = E_ALL & ~E_NOTICE 

Step 6: Test that extension is enabled and works by either calling a phpinfo() function from a script or by running a buggy script:



The Xdebug extension provides a lot of useful features that help with debugging of PHP applications. You can learn more about them from the Xdebug documentation. For example you can use it to profile a PHP application. Just change the php.ini file as shown below and then make a request to a PHP script:

[xdebug] 
zend_extension = C:\Program Files\iis express\PHP\v5.2\ext\php_xdebug-2.1.0-5.2-vc6-nts.dll  
xdebug.profiler_enable = On  
xdebug.profiler_output_dir = C:\Windows\temp 

The profile log will be saved into the specified directory and will have a name cachegrind.out.* Use WinCacheGrind to open and analyze it:

HostForLIFE.EU has supported Web Deploy technique on all our hosting plans. With a web deploy technique, a customer can efficiently synchronize sites, applications or servers across your IIS 7.0 server farm by detecting differences between the source and destination content and transferring only those changes which need synchronization.

What is Web Deploy 2.0?

Web Deploy (Web Deployment Tool) simplifies the migration, management and deployment of IIS Web servers, Web applications and Web sites. Administrators can use command-line scripting with Web Deploy to synchronize IIS 6.0 and IIS 7.0 servers or to migrate an IIS 6.0 server to IIS 7.0. Web Deploy Tool also enables administrators and delegated users to use IIS Manager to deploy ASP.NET and PHP applications to an IIS 7.0 server. 

Web Deploy 2.0 Features             

·    Seamless integration with IIS 7.0 Manager and Visual Studio 2010 interface for creating packages and deploying them onto a machine, both locally and remotely

·    Seamless integration with the Web Platform Installer to install community web applications simply and easily.

·    Web application packaging

·    Web application deployment

·    Web server migration and synchronization

·    In addition to the IIS Manager and Visual Studio 10, tasks can be performed using the command-line or public APIs.

WebMatrix is a free tool from Microsoft that makes the task of creating, editing and publishing your website easy. It allows you to intelligently publish only the files that have changed locally, automatically configure your server for maximum compatibility, and keep your development environment in sync with the live published version of your site.

In order to build sites using WebMatrix, you'll first need to install it on your local computer or development machine.  Click here for the download.

In order to publish sites to our servers using WebMatrix, you'll need to be sure your plan supports it. Currently all ASP.NET plans hosted on Windows 2008/IIS7 and ColdFusion 9 plans support WebMatrix.

Once you're ready to publish your site onto our live servers, you'll need to configure your Publish Settings.

1. First, be sure you're on the Site view in WebMatrix.



2. Go to the Publish drop down, under the Home tab, then select Settings.



3. From Publish Settings, select the Web Deploy protocol from the drop down (alternately, you can use FTP).

4. For Server, enter in your site's IP address.

5. For User Name, enter a valid Site User set up on your account.  If you recently ordered your site, this would be the username you set up during signup.

6. For Password, enter in the password associated with your Site Username.

7. For Site Name, enter in your domain name without the extension (e.g. .com, .net, .org, etc.), and the words "web site" after it.  For example, if your domain was "domain.com", you would enter "domain web site" in the Site Name field.  The site name is based on how your site's name is entered in IIS, and this is the naming convention we use to identify your site on the server.

8. For Destination URL, enter in the URL for the web site/application you're publishing.



9. To ensure your Web Deploy settings in WebMatrix is correct or working correctly, click Validate Connection.

WebMatrix is ready.

10. To create a Database connection, be sure your in the Databases view.

11. Under the Home tab, select New Connection.



To connect to a database, you'll need to:

1. Enter in your database name

2. The database type.

3. The server location. 

4. And then your database Login and Password.



Database Connection Strings

SQL Server Database
Data Source=myServerAddress;Initial Catalog=myDataBase;User Id=myUsername;Password=myPassword;

MySQL Database
Data Source=myServerAddress;Initial Catalog=myDataBase;User Id=myUsername;Password=myPassword;

Developing database-driven websites using the ASP.NET Web Pages Framework, WebMatrix and Razor is not evil as most professional ASP.NET Web Developers might think. It is hard to look back on the 90's and Classic ASP websites with much optimism as ADO, millions of include files, and spaghetti code literally became the norm. Maintaining them was an utter nightmare in most cases.

This is a different time, however, and Microsoft.Data.dll is much better than ADO, the Razor Syntax is much better than VBScript, and a lot of the security concerns around Encoding, SQL Injection, proper validation, etc. are much more well-known and publicized than it was when Classic ASP first came on the scene. At the time, we also didn't have other frameworks, like WebForms and ASP.NET MVC, and other options for data access, like LINQ To SQL and Entity Framework, so we were pretty stuck making all kinds of crazy mistakes given there wasn't another avenue for more complicated websites.

WebMatrix, the ASP.NET Web Pages Framework with Razor, and Microsoft.Data.dll fit a particular need and development environment around simple, forms-over-data websites that are nothing more than a thin layer on top of a database. Personally, at this level, anything that attempts to abstract the fact that we are just pumping data from the database onto a web page is overcomplicating the issue and making the application more difficult to maintain.

As an example, take your typical Recent News or Recent Posts page on a personal website that literally pulls data from a single table based on either a publication date or id. I see no reason to create an ASP.NET MVC or WebForms website in Visual Studio with an O/R Mapper, Visual Designer, codebehind files, view model, a bloated web.config, and other nonsense when you can just take your favorite text editor and add a few lines of Razor syntax into a page in a few minutes with a much simpler deployment model.



This is far more easier to maintain than a similar application written with ASP.NET WebForms or ASP.NET MVC. Here we have 1 file that can easily be understood in any text editor with a clear understanding that this data is coming from a database using a particular query and dumped onto a web page. Want to sort it differently? Want to display more than 20 stories? It is pretty darn clear and pretty darn easy to make those changes and any changes that fit this simple, database-driven niche.

Other than those 3 lines at the top this looks pretty close to a view in the ASP.NET MVC Framework. If things get much more complicated and you need to offer a layer of abstraction and separate out concerns, you could move those 3 lines out of the view and migrate to MVC. I suspect such an application wouldn't grow to such a need, but if it does, there is a path to a more appropriate framework.

Also noticed that by default everything is HTML Encoded with less chance for JavaScript Injection. I have to work around the framework and use an HtmlString to display the body of the post to allow raw HTML to be displayed. We didn't have automatic encoding with Classic ASP :)

Although nothing is perfect and mistakes will be made by new developers, it won't be anything like the 90's and Classic ASP. This is good stuff for simple forms-over-data websites. As professional web developers I realize we worked long and hard to learn how to properly architect complex web applications, but I think the pendulum may have swung a bit too far and we forget the joy, ease, and beauty of developing simple websites using simple techniques and simple tools.