Windows 2003 Server SP1 Firewall Modification for Passive or PASV FTP Connections

(Portions of this document are parphrased from or directly copied from Microsoft KB article 555022 by Bernard Cheah, MVP.)

Passive Mode FTP connections are normally required by clients connecting through a NAT firewall or router. The client connects on port 21 and issues a PASV command, the server responds with a port in the 1024-65535 range for the data connection. After a data connection command is issued by the client, the server connects to the client using the port immediately above the client-side port of the control connection. The Windows 2003 SP1 Firewall will prevent PASV FTP from working properly unless exceptions for the ports are created. A metabase property key named PassivePortRange can be configured to specify the port range the server will respond with. This can be used to limit the security risk for the FTP server. The property key only exists in IIS 6.0. Support for IIS 5.0 on Windows 2000 can be added, but the system administrator will need to install Service Pack 4 and add the PassivePortRange key in the system registry. Two ports must be opened for each concurrent FTP connection.

On Windows 2003 Server with IIS6

• To Enable Direct Metabase Edit
  1. Open the IIS Microsoft Management Console (MMC).
  2. Right-click on the Local Computer node.
  3. Select Properties.
  4. Make sure the Enable Direct Metabase Edit checkbox is checked.
• Configure PassivePortRange via ADSUTIL script
  1. Click Start, click Run, type cmd, and then click OK.
  2. Type cd Inetpub\AdminScripts and then press ENTER.
  3. Type the following command where the range is specified in "..". cscript.exe adsutil.vbs set /MSFTPSVC/PassivePortRange "5001-5201"
  4. Restart the FTP Publishing Service.
  You'll see the following output, when you configure via ADSUTIL script:
  Microsoft (R) Windows Script Host Version 5.6
  Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
  PassivePortRange : (STRING) "5001-5201"

 

It's crazy to add 201 exceptions rules. Just disable the windows firewall temporarily.

• Add each port to the Windows Firewall
  1. Click Start, click Control Panel, open Windows Firewall, and select the Exceptions tab.
  2. Click the Add Port button.
  3. Enter a Name for the Exception and the first number in the port range.
  4. Click TCP if not already selected and click OK.
  5. Repeat for each port in the range - for large ranges see the end of the document.
  6. Enable the Windows Firewall on the General Tab.

IIS 6 doesn't handle extensionless URLs. You'll need to change your routes to use the .mvc extension.

For example,

  routes.Add(new Route("Links.mvc/{categoryName}",...

Make sure that IIS 6 maps .mvc to the aspnet_isapi.dll.

Tame Your Software Dependencies for More Flexible Apps

http://msdn2.microsoft.com/en-us/magazine/cc337885.aspx

http://www.xfront.com/REST-Web-Services.html

What is REST?

REST is a term coined by Roy Fielding in his Ph.D. dissertation [1] to describe an architecture style of networked systems. REST is an acronym standing for Representational State Transfer.

REST - An Architectural Style, Not a Standard

REST is not a standard. You will not see the W3C putting out a REST specification. You will not see IBM or Microsoft or Sun selling a REST developer's toolkit. Why? Because REST is just an architectural style. You can't bottle up that style. You can only understand it, and design your Web services in that style. (Analogous to the client-server architectural style. There is no client-server standard.)

While REST is not a standard, it does use standards:

• HTTP
• URL
• XML/HTML/GIF/JPEG/etc (Resource Representations)
• text/xml, text/html, image/gif, image/jpeg, etc (MIME Types)

The Classic REST System

The Web is a REST system! Many of those Web services that you have been using these many years - book-ordering services, search services, online dictionary services, etc - are REST-based Web services. Alas, you have been using REST, building REST services and you didn't even know it.

REST is concerned with the "big picture" of the Web. It does not deal with implementation details (e.g., using Java servlets or CGI to implement a Web service). So let's look at an example of creating a Web service from the REST "big picture" perspective.

REST Web Services Characteristics

Here are the characteristics of REST:

• Client-Server: a pull-based interaction style: consuming components pull representations.
• Stateless: each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server.
• Cache: to improve network efficiency responses must be capable of being labeled as cacheable or non-cacheable.
• Uniform interface: all resources are accessed with a generic interface (e.g., HTTP GET, POST, PUT, DELETE).
• Named resources - the system is comprised of resources which are named using a URL.
• Interconnected resource representations - the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another.
• Layered components - intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, etc.

Principles of REST Web Service Design

1. The key to creating Web Services in a REST network (i.e., the Web) is to identify all of the conceptual entities that you wish to expose as services. Above we saw some examples of resources: parts list, detailed part data, purchase order.

2. Create a URL to each resource. The resources should be nouns, not verbs. For example, do not use this:

http://www.parts-depot.com/parts/getPart?id=00345

Note the verb, getPart. Instead, use a noun:

http://www.parts-depot.com/parts/00345

3. Categorize your resources according to whether clients can just receive a representation of the resource, or whether clients can modify (add to) the resource. For the former, make those resources accessible using an HTTP GET. For the later, make those resources accessible using HTTP POST, PUT, and/or DELETE.

4. All resources accessible via HTTP GET should be side-effect free. That is, the resource should just return a representation of the resource. Invoking the resource should not result in modifying the resource.

5. No man/woman is an island. Likewise, no representation should be an island. In other words, put hyperlinks within resource representations to enable clients to drill down for more information, and/or to obtain related information.

6. Design to reveal data gradually. Don't reveal everything in a single response document. Provide hyperlinks to obtain more details.

7. Specify the format of response data using a schema (DTD, W3C Schema, RelaxNG, or Schematron). For those services that require a POST or PUT to it, also provide a schema to specify the format of the response.

8. Describe how your services are to be invoked using either a WSDL document, or simply an HTML document.

http://www.infoq.com/articles/rest-introduction

Key REST principles

Most introductions to REST start with the formal definition and background. I’ll defer this for a while and provide a simplified, pragmatic definition: REST is a set of principles that define how Web standards, such as HTTP and URIs, are supposed to be used (which often differs quite a bit from what many people actually do). The promise is that if you adhere to REST principles while designing your application, you will end up with a system that exploits the Web’s architecture to your benefit. In summary, the five key principles are:

• Give every “thing” an ID
• Link things together
• Use standard methods
• Resources with multiple representations
• Communicate statelessly

The WIN key is actually very versatile and goes to the heart of being able to whizz around your desktop without the mouse. For example, if you do WIN + R, you can get the Run box (try it). WIN + E opens Explorer (your hard drive), WIN + D minimises all your windows and takes you to the desktop, WIN+L locks your screen and WIN + TAB moves you from one open application to another.

CTRL + P   Print

http://learn.iis.net/page.aspx/387/using-visual-studio-2008-with-iis-70/

Using Visual Studio 2008 with IIS 7.0

Author: Mike Volodarsky

Published on March 05, 2008 by mvolo

Updated on March 12, 2008 by mvolo

Average Rating   Rate It (0) Thank you for your feedback!

Tags

IIS 7.0 Visual Studio 2008 debugging publishing web site web application

Introduction

Visual Studio® provides several options for working with IIS when developing web sites and applications. These include the Web application and Web site projects.  In Visual Studio 2008, these features receive a much awaited upgrade to properly support IIS 7.0 in Windows Vista® and Windows Server® 2008. In addition, the recently released Web Deployment Project 2008 also provides support for IIS 7.0.

This article provides an overview of using Visual Studio 2008 Web development features with IIS 7.0, including information on the steps necessary to enable these features to work correctly.

Prerequisites

To use Visual Studio 2008 to work with Web sites and applications on your local machine, do the following:

1. Install IIS 7.0
2. Install ASP.NET
3. Install IIS 6.0 Metabase Compatibility
On Windows Vista, open the Control Panel, click Programs and Features, click the Turn Windows features on and off link, check the “Internet Information Services” check box, as well as the “Web Management Tools \ IIS 6 Management Compatibility \ IIS Metabase and IIS 6 configuration compatibility” and “World Wide Web Services \ Application Development Features \ ASP.NET” check boxes under it.  

On Windows Server 2008, use the Server Manager tool to install the Web Server (IIS) role, and add the “Management Tools \ IIS 6 Management Compatibility \ IIS 6 Metabase Compatibility” and “Application Development \ ASP.NET“ role services. For more information, see Installing IIS 7.0 on Windows Server 2008.

To use Visual Studio 2008 to work with Web sites and applications on a remote machine, see the "Using Visual Studio 2008 with a Remote IIS 7.0 Server" section later in this article.

Starting Visual Studio 2008 as Administrator

Certain tasks, including debugging and creating local IIS applications, require starting Visual Studio as a user with Administrative privileges. On Windows Vista, and Windows Server 2008 when not running as the built-in Administrator account, this requires right-clicking the Visual Studio 2008 icon in the Start Menu and choosing “Run As Administrator”.

To make this process easier, you can create a shortcut and check the “Run this program as an administrator” check box in the Compatibility tab of the shortcut properties.

Create a New IIS 7.0 Web Site or Application Project

Visual Studio provides two conceptual models for working with Web applications: the Web site project model, and the Web application project model.

While both options allow you to create Web applications and publish them to an IIS 7.0 server, they do have significant differences in how the corresponding ASP.NET application is built and deployed. Some of the differences between the two models are:

• The Web application project option requires the source application files to be located on the local file system, or, on a network share. However, you can subsequently publish the Web application to a remote IIS 7.0 Web site by using a network share, FTP, or Front Page Server Extensions.
• The Web site project option allows you to connect directly to a local IIS 7.0 Web site, or to a remote IIS 7.0 Web site by using a network share, FTP, or Front Page Server Extensions. With the Web site project, you work directly with the content of your IIS 7.0 Web site and there is no project file.

You can find the detailed explanation of the two models and their differences in http://msdn2.microsoft.com/en-us/library/aa730880(VS.80).aspx.

Note: Visual Studio 2008 provides the options to create a New project and Open an existing project.  This does not necessarily mean that you must create a new IIS web application or open an existing application – you can use either of the options with an existing IIS web application.

To create a new project using the Web application project option:

• In Visual Studio, use the “File menu \ New \ Project ...” option and select the “ASP.NET Web Application” template.

Note: Unlike the Web site project option, you must place the application files on the local file system or a network share, and later use the Publish option to publish the contents of your application to an IIS 7.0 Web site.

To publish the project to an IIS 7.0 Web site:

1. Create the IIS 7.0 Web site using IIS Manager, AppCmd, or another configuration tool.

For more information, see http://technet2.microsoft.com/windowsserver2008/en/library/f6c26eb7-ad7e-4fe2-9239-9f5aa4ff44ce1033.mspx?mfr=true. Alternatively, use an existing IIS 7.0 Web site.

2. In Visual Studio, use the "Build \ Publish" option to publish the contents of your Web application to an IIS 7.0 Web site.

Note: The Publish Web dialog by default publishes only the parts of your project that comprise your web application - it does not publish the project file, obj directory, and other files. This is important because exposing these components to your web users may be a security risk.

By clicking the "…" button, you can chose one of the four options for publishing your Web site:

• File System. When using this option, Visual Studio opens / creates the web application as a folder, and uses the built-in ASP.NET Development Server to host the Web site. This option may be sufficient for basic testing of ASP.NET applications – however, this mode does not support running ASP.NET applications in Integrated mode, and it does not support application technologies other than ASP.NET (such as PHP, ASP, CGI, etc).
• Local IIS. When using this option, Visual Studio allows you to publish your application files to a local IIS 7.0 Web site or application. You can also use the dialog to create new IIS 7.0 applications or virtual directories to publish your files to.
• FTP Site. When using this option, Visual Studio supports editing your application files if they are shared through FTP.  You can still use Visual Studio to debug your applications by configuring the URL of your application in project start settings. For more information, see Using Visual Studio 2008 with a Remote IIS 7.0 Server section later in this article.
• Remote Site. Using this option, Visual Studio can connect to a remote IIS server. To use this option, you need to have Front Page Server Extensions installed on the remote server and configure your Web site to use FPSE.  For more information on this, see the "Using Visual Studio 2008 with a Remote IIS 7.0 Server" section later in this article.

You can also map the Web application project directory as a virtual directory on the local IIS 7.0 installation by opening the project Properties, clicking the “Web” tab, and using the “Create Virtual Directory” button.  You can use the “Create Virtual Directory” option as a quick way to host your Web application locally on IIS without going through the “Publish Web” option.

However, this option is not generally recommended because it places all of the project files, source files, object files, and other temporary files in the servable namespace of the IIS 7.0 virtual directory, which may result in a security risk.  Using the Publish options which by default only publish the web servable portions of the project is a better practice.

3. Configure debugging.

By default, projects created using the Web application project model use the built-in ASP.NET Development Server when testing or debugging your project.

This provides a convenient way to test your ASP.NET application without IIS 7.0 – however, we recommend that you instead configure Visual Studio to test your application in the IIS 7.0 environment.  The reasons for this are:

• The ASP.NET Development Server does not support hosting ASP.NET applications in Integrated mode, which is the default mode of operation used by IIS 7.0. This may introduce differences in application behavior. 
• The ASP.NET Development Server does not support many of the IIS configuration features, so if your application relies or uses them, it’s behavior may be different or incorrect when hosted under the ASP.NET Development Server.
• The ASP.NET Development Server does not support hosting portions of your application that utilize application technologies other than ASP.NET, such as PHP, CGI, and other third party frameworks.

If you are developing on Windows Vista, you can easily take advantage of IIS 7.0 to test your application locally using the same environment it will be on when it is deployed - use the "Create Virtual Directory" option or the Publish Web dialog as discussed earlier in this article. 

Alternatively, you can configure Visual Studio to connect to the a remote IIS 7.0 server to which you publish your application.

In those cases, you can configure Visual Studio to debug your application in the IIS 7.0 environment. To do this, right-click on the project node, chose "Properties …", and click the "Web" tab.  In the "Web" tab, select the "Use IIS Web server" radio button and type in the base URL of your Web application on the remote server.

For more information on configuring remote debugging, see "Debugging IIS 7.0 Web Applications" later in this article.

To create a new project using the Web site project option:

1. Create the IIS 7.0 Web site using IIS Manager, AppCmd, or another configuration tool. For more information, see http://technet2.microsoft.com/windowsserver2008/en/library/f6c26eb7-ad7e-4fe2-9239-9f5aa4ff44ce1033.mspx?mfr=true. Alternatively, use an existing IIS 7.0 Web site.

2. In Visual Studio, use the “File menu \ New \ Web Site …” option to create a new Web site project using the IIS 7.0 Web site you created.

In the “New Web Site” dialog, select one of the Visual Studio Web site templates, such as the ASP.NET Web Site.

Next, indicate where this web site should be located. To do this, click the “Browse …” button, which displays a dialog similar to what you get when publishing a Web application project.  Here, click the “Local IIS” button again to select an existing Web site or application on the local machine, or create a new Web application or virtual directory to host your project files. 

Alternatively, you will have the option to place your new Web site project on the local File System for use with the ASP.NET Development Server, upload it to a remote server using FTP, or upload it to a remote IIS server using Front Page Extensions.  For more information on connecting to a remote server, see the "Using Visual Studio 2008 with a Remote IIS 7.0 Server" section later in this article.

To Open an Existing IIS 7.0 Web Site or Application

To create a project based on an existing IIS 7.0 Web site:

1. Open the existing IIS 7.0 Web site using the “File menu \ Open \ Web Site …” option. 

Click “Local IIS” to connect to the local IIS 7.0 server. 

In the resulting dialog, you can select the Web site or a child application to open.  Alternatively, you can use the “Create New Web Application”, “Create New Virtual Directory”, and “Delete” buttons in the top right hand corner to manage the web site hierarchy.

Note: Be sure to back up your configuration first before making changes.

If you do not have IIS 7.0 or any of the prerequisites installed, Visual Studio 2008 displays a message when you attempt to connect to the Local IIS server telling you to install the required components. To do this, see the "Prerequisites" section earlier in this article.

Note: Visual Studio provides several different options for working with existing Web sites, in addition to connecting to an existing IIS 7.0 Web site. These options include:

• File System. When using this option, Visual Studio opens / creates the web application as a folder, and uses the built-in ASP.NET Development Server to host the Web site. You can use this option to connect to an existing IIS 7.0 web site by opening its virtual directory’s root folder on the local file system or through a network share.
• FTP Site. When using this option, Visual Studio supports editing your application files if they are shared through FTP. For more information, see the "Using Visual Studio 2008 with a Remote IIS 7.0 Server" section later in this article.
• Remote Site. Using this option, Visual Studio can connect to a remote IIS server. To use this option, you need to have Front Page Server Extensions installed on the remote server and configure your Web site to use FPSE.  For more information on this, see the "Using Visual Studio 2008 with a Remote IIS 7.0 Server" section later in this article.

2. Configure debugging. 

If you have opened an existing IIS 7.0 Web site using the Local IIS or Remote Site options, your project is automatically configured to use the IIS 7.0 Web site when debugging so no further action is necessary (the Remote Site option requires additional configuration to enable remote debugging, as explained later in the article). 

If you have opened your Web site project using the File System or FTP site options, it is by default configured to use the ASP.NET Development Server for testing and debugging. It is recommended that you configure Visual Studio to use the IIS 7.0 server on which the Web site is located for debugging.

To do this, right-click on the Web site project node, chose "Start Options ...".  In the dialog, select "Use custom server" radio button and type in the base URL of your Web application on the remote server.

Using Visual Studio 2008 with a Remote IIS 7.0 Server

In order to open an existing Web site or create a new Web site on a remote IIS server, you can use many of the options mentioned earlier:

• File System. You can create a file share pointing to the root virtual directory of your Web application, and use the "File System" option to connect to it.  To use this option, select the "File System" button in the “Open Web Site” dialog. You then have to configure the URL of your application in project start settings to be able to debug the application using Visual Studio. You cannot create new IIS Web sites, applications, or virtual directories on the remote machine using this option.

• FTP Site. If your Web site or application files are shared using FTP, you can access these files using this option. You then have to configure the URL of your application in project start settings to be able to debug the application using Visual Studio. To use this option, select the "FTP Site" button in the "Open Web Site" dialog.  You cannot create new IIS Web sites, applications, or virtual directories on the remote machine using this option.

• Remote Site.  This option uses Front Page Server Extensions to connect to a remote IIS server.  To use this option to connect to a remote IIS 7.0 server on Windows Server 2008 or Windows Vista computers, you first need to install Front Page Server Extensions on the remote computer.

Connect to an IIS 7.0 Web site using FTP

You can use the FTP Site option if you have used FTP to share the IIS 7.0 virtual directory you want to publish to.

Note: When using FTP, you cannot create or edit IIS 7.0 Web sites, applications, or virtual directories, but you can publish and edit files.

To use this option, provide the address of the FTP server, the port, the directory to which you are connecting, and logon credentials if not using anonymous access.

For more information on using the FTP server included in Windows Vista and Windows Server 2008, see FTP Site Setup (IIS 6.0). To use the new FTP 7.0, which is available as a download from IIS.NET, see Adding FTP to a Web Site.

Connect to an IIS 7.0 Web Site Using Front Page Server Extensions

You can use the Remote Site option if you have shared the IIS 7.0 Web site you want to publish to using Front Page Server Extensions. Unlike the FTP Site option, you can create and edit IIS 7.0 applications and virtual directories when using this option.

Front Page Server Extensions for IIS 7.0 are available as a free download for Windows Vista and Windows Server 2008.   For more information on installing and enabling Front Page Server Extensions for IIS 7.0 Web sites, see Installing Front Page Server Extensions for IIS 7.0.

To quickly enable a remote Web site to be used with the “Remote Site” option in Visual Studio, do the following:

1. Download and install FPSE on the remote IIS 7.0 server. The provided installer automatically installs all required IIS 7.0 components.

2. Create an IIS 7.0 web site to connect to (optional, if the site does not already exist).

3. Enable either Basic Authentication or Windows Authentication methods for the Web site. This is required for FPSE to be able to manage the site.

Note: If you use Basic authentication, the username and password are transmitted in clear text so you should not use it for connecting to web sites over public networks unless you also use SSL to protect the communication.

4. Enable the web site to be managed with FPSE. You can do this by executing the following from the command line:

> "%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\50\bin\owsadm.exe" -o install -p LM/W3SVC/<SITEID> -u <USERNAME>

Where <SITEID> is the site id of the Web site you want to enable for FPSE, and the <USERNAME> is the Windows account that can act as FPSE administrator.

5. Connect to the site Using the “Remote Site” option in the Open Web Site dialog or the New Site dialog. This allows you to connect to an existing Front Page Server Extensions – enabled web site, or create new Web applications and virtual directories.

If you receive the following error dialog during connection, double-check that you have installed FPSE on the remote server, and have enabled FPSE management for the Web site you are attempting to connect to.

If you are using Windows authentication for your FPSE-enabled Web site, Visual Studio attempts to authenticate using the account under which it was started.  If this authentication fails, it prompts you to provide credentials for authentication with the remote server. 

If you are using Basic authentication, Visual Studio immediately prompts you for credentials.

Note: Basic authentication sends credentials in clear text, so it can lead to unintended disclosure of your username and password if the site is not protected with SSL. For this reason, we recommend using Windows authentication for intranet environments, and using Basic authentication over SSL for internet environments.

If you have not enabled a suitable authentication method (Windows Authentication, Basic Authentication, or Digest Authentication), you receive the following error dialog when connecting. Turn on one of the above authentication methods to fix this problem.

Note: The "New Web Site …" button in the "Remote Site" dialog cannot be used to create a new IIS 7.0 Web site.  Instead, it is used to create a new Web application with the specified path for an existing Front Page Server Extensions – enabled IIS 7.0 Web site.

Debugging IIS 7.0 Web Applications

After you have opened a Web site or application in Visual Studio, you can take advantage of Visual Studio debugging features to test it. In doing so, you have the following options:

• Use F5 debugging to debug from Visual Studio. If you have opened an IIS 7.0 Web site project using one of the options discussed earlier, this gives you the most convenient way to debug your web application. You can debug it simply by pressing F5, and then interacting with your application using a browser window. In the rest of this article, we will focus on this option.
• Attach to the IIS worker process directly. If you know which IIS worker process is hosting your application, you can use this option to attach directly to that process.

Use F5 to Debug a Local IIS 7.0 Web Application from Visual Studio

F5 debugging provides the most convenient way to debug your Web application with Visual Studio. To use it, do the following:

1. Open an IIS 7.0 Web site using one of the options discussed earlier.

2. Select the project file to which you want to make the initial request (optional).

3. Set the desired breakpoints in your application source code (optional, you can also set them during debugging).

4. Press F5 to begin debugging.  Visual Studio will make an initial request to the IIS 7.0 web application, attach to the hosting IIS worker process, and open a new browser window where you can interact with your application.

In order to successfully debug a local IIS 7.0 Web application, you must meet the following requirements:

1. Be logged on as a user that has Administrative privileges on the local computer (Either the built-in Administrator account, or an account that is a member of the built-in Administrators group).

2. Start Visual Studio in Administrator mode by right-clicking the Visual Studio 2008 icon in the Start menu, and selecting “Run As Administrator”. 

If you do not do this, Visual Studio receives a filtered UAC token and cannot debug.

If you have opened an ASP.NET application using the “File System” option, Visual Studio by default starts the ASP.NET Development Server to host your application.  In this option, IIS 7.0 is not involved, and you are not required to be an Administrator to debug your application.

However, when using the ASP.NET Development Server, you do not have the full range of features and services that IIS 7.0 environment provides, which may make your application behave differently from when it is deployed on IIS 7.0. This includes the following:

• No support for ASP.NET Integrated Mode.
• No support for IIS 7.0 features such as compression, native URL authentication, request filtering, and others.
• No support for application technologies other than ASP.NET, such as PHP, ASP, CGI, and others.

Use F5 to Debug a Remote IIS 7.0 Web Application from Visual Studio

You can use F5 to debug an IIS 7.0 Web application running on a remote server. The process is similar to what was described earlier for debugging local IIS 7.0 applications, but requires additional configuration to enable remote debugging to take place.

In addition, you must open the remote IIS 7.0 Web site or application project using the File System, FTP Site or Remote Site options as discussed in the "Using Visual Studio 2008 with a Remote IIS 7.0 Server" section earlier in this article.

In order to successfully debug a remote application, you must also meet the following requirements:

1. Install the Remote Debugging components on the server machine. For more information, see How to: Set Up Remote Debugging.

2. Run the Remote Debugging monitor (msvsmon.exe) on the server machine.  See notes further about how to do this properly.

3. Open the required firewall ports for remote debugging. 

When you run msvsmon.exe for the first time on the remote machine, it warns you if the ports are not open, and offers to open them automatically. If you want to configure the firewall manually or to see which ports are opened, see How to: Manually Configure the Windows Vista Firewall for Remote Debugging.

4. If you are using a Web application project and publishing to a remote IIS 7.0 server, or if you have opened the remote Web site project using the "File System" or "FTP Site" options, you must configure Visual Studio project start options to enable debugging.

To do this for a Web site project, right-click on the Web site project node, chose "Start Options …".  In the dialog, select "Use custom server" radio button and type in the base URL of your Web application on the remote server.

For a Web application project, right-click on the project node, chose "Properties …", and click the "Web" tab.  In the "Web" tab, select the "Use IIS Web server" radio button and type in the base URL of your Web application on the remote server.

This process is described in detail earlier in the article.

5. Configure permissions to allow debugging to take place.  See notes further about how to do this properly.

How you run the Remote Debugging monitor (msvsmon.exe) and configure your permissions depends on whether your are operating in a domain or workgroup environment.

To set up remote debugging in a workgroup environment

1. Create an account with the same username and password on both the Visual Studio 2008 client computer and the remote server computer. This account must have Administrative rights on the remote server computer.

Note: If you are using Windows Authentication in your application, this account must be the built-in Administrator account.  This means that the built-in Administrator account must have the same password on both computers.

2. Log on to the remote server computer using the account created in Step 1, and run the Visual Studio 2008 Remote Debugger from the Start menu by right-clicking it, and choosing "Run As Administrator".

This is important – otherwise the Remote Debugging monitor receives a UAC-filtered token and cannot debug IIS worker processes.

Note: Do not use the RunAs.exe command to run the msvsmon.exe process, as this always results in a UAC-filtered token and prevents debugging from working.

You also have an option to run the Remote Debugging monitor as a service by opening the Visual Studio 2008 Remote Debugger Configuration Wizard from the Start menu.  If using this option, you must configure the Remote Debugging monitor to log on using the account created in Step 1.  You then also must grant the corresponding account the "Log On As A Service" right in the computer’s Local Security Policy console.

3. Log on to the Visual Studio 2008 client computer with the account created in step #1.  Run Visual Studio 2008 by right-clicking its icon in the Start menu, and choosing "Run As Administrator".

Note: It is very important to both log in using the account created in Step 1, and use the "Run As Administrator" option when running Visual Studio.  As mentioned in Step 1, the account you are using MUST be an Administrative user on the remote server machine.

4. Open the remote IIS 7.0 Web site (using the File System, FTP Site or the Remote Site option).

If you are using Windows Authentication in your IIS 7.0 Web site, you must be running Visual Studio 2008 using the built-in Administrator account and therefore also running the Remote Debugging monitor on the remote computer using the built-in Administrator account. The password for the Administrator account must be the same on the client and remote server computers.

In addition, you can do the following:

• Use the FTP Site option to connect to the remote IIS 7.0 Web site, and use Anonymous authentication. Then, you do not need to use the built-in Administrator account, as long as the account you are using is an Administrative user on the remote server computer.

• Use the Remote Site option to connect to the remote IIS 7.0 Web site, and use Basic or Digest authentication. Then, you do not need to use the built-in Administrator account, as long as the account you are using is an Administrative user on the remote server computer.

If you need to use Windows Authentication in your IIS 7.0 Web site, and you cannot use synchronized Administrator accounts, you must turn off UAC on the remote server computer and reboot prior to attempting to debug.  This is not recommended for production servers as it may negatively affect the security of your server.

To set up remote debugging in a domain environment

Debugging in a domain environment is simpler to configure. To debug in a domain environment, you must:

1. Make the domain account you will be using to run Visual Studio 2008 a member of the Administrators group on the remote server computer.

2. Log on to the remote server computer using the domain account, and run the Remote Debugging monitor (msvsmon.exe) using the "Run As Administrator" option.

You also have an option to run the Remote Debugging monitor as a service by right clicking the Visual Studio 2008 Remote Debugger Configuration Wizard from the Start menu, and choosing "Run As Administrator".  You can let the Remote Debugging monitor service run as LocalSystem.

3. Log on to the Visual Studio 2008 client computer with the domain account.  Run Visual Studio 2008 by right-clicking its icon in the Start menu, and choosing "Run As Administrator".

4. Open the remote IIS 7.0 Web site using the FTP Site or the Remote Site option.

http://www.odesk.com/w/

simply track，http://www.vbssol.com/

Trade Log  https://www.armencomp.com/purchase.html

How to uninstall an application when it does not appear in Add/Remove Programs

http://blogs.msdn.com/astebner/archive/2005/10/30/487096.aspx

http://blogs.msdn.com/varungupta/archive/2007/12/04/visual-studio-2008-setup-troubleshooting-guide.aspx

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2519361&SiteID=1

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2519361&SiteID=1

http://weblogs.asp.net/scottgu/archive/2007/11/19/visual-studio-2008-and-net-3-5-released.aspx

 

Quick Tour of Some of the New Features

Visual Studio 2008 and .NET 3.5 contain a ton of new functionality and improvements.  Below are links to blog posts I've done myself as well as links to videos you can watch to learn more about it:

VS 2008 Multi-Targeting Support

VS 2008 enables you to build applications that target multiple versions of the .NET Framework.  This means you can use VS 2008 to open, edit and build existing .NET 2.0 and ASP.NET 2.0 applications (including ASP.NET 2.0 applications using ASP.NET AJAX 1.0), and continue to deploy these application on .NET 2.0 machines.  You can learn more about how this works from my blog post here:

• VS 2008 Multi-Targeting Support

ASP.NET AJAX and JavaScript Support

.NET 3.5 has ASP.NET AJAX built-in (no separate download required).  In addition to including all of the features in ASP.NET AJAX 1.0, ASP.NET 3.5 also now includes richer support for UpdatePanels integrating with WebParts, ASP.NET AJAX integration with controls like <asp:menu> and <asp:treeview>, WCF support for JSON, and many other AJAX improvements.

VS 2008 and Visual Web Developer 2008 also now have great support for integrating JavaScript and AJAX into your applications.  You can learn more about this from my blog posts here:

• VS 2008 JavaScript Intellisense
• VS 2008 JavaScript Debugging
• VS 2008 ASP.NET AJAX Control Extender Support
• VS 2008 JavaScript Intellisense for Silverlight

You can watch some videos that discuss ASP.NET AJAX and Visual Studio 2008 support for it here. 

I also highly recommend the excellent ASP.NET AJAX in Action book to learn more about ASP.NET AJAX (both client-side and server-side).

VS 2008 Web Designer and CSS Support

VS 2008 and Visual Web Developer 2008 Express includes a significantly improved HTML web designer (the same one that ships with Expression Web).  This delivers support for split-view editing, nested master pages, and great CSS integration.  Below are some articles I've written that discuss this more:

• VS 2008 Web Designer and CSS Support
• VS 2008 Nested Master Page Support
• VS 2008 Vertical Split View Support
• VS 2008 Support to Treat CSS and JavaScript Validation Issues as Warnings instead of Errors

ASP.NET 3.5 also has a new <asp:ListView> control that provides the ability to perform rich data scenarios with total control over the markup.  It works nicely with the new CSS support in VS 2008.  You can learn more about it from my article here:

• ASP.NET 3.5 ListView Control

You can watch some videos that discuss the new Visual Studio 2008 web designer features and the new ListView/DataPager controls here. 

Language Improvements and LINQ

The new VB and C# compilers in VS 2008 deliver significant improvements to the languages.  Both add functional programming concepts that enable you to write cleaner, terser, and more expressive code.  These features also enable a new programming model we call LINQ (language integrated query) that makes querying and working with data a first-class programming concept with .NET. 

Below are some of the articles I've written that explore these new language features using C#:

• Automatic Properties, Object Initializer and Collection Initializers
• Extension Methods
• Lambda Expressions
• Query Syntax
• Anonymous Types

Here are a few additional blog posts I've written that show off some of the new VS 2008 code editing support and some cool ways to use these new language features:

• VS 2008 Code Editing Features
• Tip/Trick: Building a ToJson() Extension Method using .NET 3.5
• The C# ?? null coalescing operator (and using it with LINQ)
• Using LINQ to XML (and how to build a custom RSS Feed Reader with it)

The Visual Basic team has also created some great free videos that cover LINQ.  You can watch them here.

Data Access Improvements with LINQ to SQL

LINQ to SQL is a built-in OR/M (object relational mapper) in .NET 3.5.  It enables you to model relational databases using a .NET object model.  You can then query the database using LINQ, as well as update/insert/delete data from it.  LINQ to SQL fully supports transactions, views, and stored procedures.  It also provides an easy way to integrate business logic and validation rules into your data model.  Below are some of the articles I've written that explore how to use it:

• Part 1: Introduction to LINQ to SQL
• Part 2: Defining our Data Model Classes
• Part 3: Querying our Database
• Part 4: Updating our Database
• Part 5: Binding UI using the ASP:LinqDataSource Control
• Part 6: Retrieving Data Using Stored Procedures
• Part 7: Updating our Database using Stored Procedures
• Part 8: Executing Custom SQL Expressions
• Part 9: Using a Custom LINQ Expression with the <asp:LinqDataSource> control

I think you'll find that LINQ and LINQ to SQL makes it much easier to build much cleaner data models, and write much cleaner data code.  I'll be adding more posts to my LINQ to SQL series in the weeks and months ahead (sorry for the delay in finishing them earlier - so much to-do and so little time to-do it all!).

Scott Stanfield is also working on creating some great LINQ to SQL videos for the www.asp.net site based on my article series above (all videos are in both VB and C#).  You can watch the first 4 videos in this series here.

Browsing the .NET Framework Library Source using Visual Studio

As I blogged a few weeks ago, we will be releasing a reference version of the .NET Framework library source code as part of this release.  Visual Studio 2008 has built-in debugger support to automatically step-into and debug this code on demand (VS 2008 can pull down the source for the appropriate .NET Framework library file automatically for you).

We are deploying the source servers to enable this right now, and will be publishing the steps to turn this feature on in the next few weeks.

Lots of other improvements

The list above is only a small set of the improvements coming.  For client development VS 2008 includes WPF designer and project support.  ClickOnce and WPF XBAPs now work with FireFox.  WinForms and WPF projects can also now use the ASP.NET Application Services (Membership, Roles, Profile) for roaming user data. 

Office development is much richer - including support for integrating with the Office 2007 ribbon, and with Outlook.  Visual Studio Tools for Office support is also now built-into Visual Studio (you no longer need to buy a separate product).

New WCF and Workflow projects and designers are now included in VS 2008.  Unit testing support is now much faster and included in VS Professional (and no longer just VSTS).  Continuous Integration support is now built-in with TFS.  AJAX web testing (unit and load) is now supported in the VS Test SKU.  And there is much, much more...

Installation Suggestions

People often ask me for suggestions on how best to upgrade from previous betas of Visual Studio 2008.  In general I'd recommend uninstalling the Beta2 bits explicitly.  As part of this you should uninstall Visual Studio 2008 Beta2, .NET Framework Beta2, as well as the Visual Studio Web Authoring Component (these are all separate installs and need to be uninstalled separately).  I then usually recommend rebooting the machine after uninstalling just to make sure everything is clean before you kick off the new install.  You can then install the final release of VS 2008 and .NET 3.5 on the machine.

Once installed, I usually recommend explicitly running the Tools->Import and Export Settings menu option, choosing the "Reset Settings" option, and then re-pick your preferred profile.  This helps ensure that older settings from the Beta2 release are no longer around (and sometimes seems to help with performance).

Note that VS 2008 runs side-by-side with VS 2005 - so it is totally fine to have both on the same machine (you will not have any problems with them on the same box).

Silverlight Tools and VS Web Deployment Project Add-Ins

Two popular add-ins to Visual Studio are not yet available to download for the final VS 2008 release.  These are the Silverlight 1.1 Tools Alpha for Visual Studio and the Web Deployment Project add-in for Visual Studio.  Our hope is to post updates to both of them to work with the final VS 2008 release in the next two weeks.  If you are doing Silverlight 1.1 development using VS 2008 Beta2 you'll want to stick with with VS 2008 Beta2 until this updated Silverlight Tools Add-In is available. 

Hope this helps,

Scott