Jack @ ASP.NET

WebsiteSpark – that Microsoft is launching today.(http://weblogs.asp.net/scottgu/archive/2009/09/24/announcing-the-websitespark-program.aspx)

WebsiteSpark is designed for independent web developers and web development companies that build web applications and web sites on behalf of others.  It enables you to get software, support and business resources from Microsoft at no cost for three years, and enables you to expand your business and build great web solutions using ASP.NET, Silverlight, SharePoint and PHP, and the open source applications built on top of them.

What does the program provide?

WebSiteSpark provides software licenses that you can use for three years at no cost.  Once enrolled, you can download and immediately use the following software from Microsoft:

• 3 licenses of Visual Studio 2008 Professional Edition
• 1 license of Expression Studio 3 (which includes Expression Blend, Sketchflow, and Web)
• 2 licenses of Expression Web 3
• 4 processor licenses of Windows Web Server 2008 R2
• 4 processor licenses of SQL Server 2008 Web Edition
• DotNetPanel control panel (enabling easy remote/hosted management of your servers)

The Windows Server and SQL Server licenses can be used for both development and production deployment.  You can either self-host the servers on your own, or use the licenses with a hoster.  WebsiteSpark makes it easy to find hosters who are also enrolled in the program, and who can use your licenses to provide you with either dedicated or virtual dedicated servers to host your sites on.

In addition to software, WebsiteSpark provides partner opportunities to grow and build your business (including customer referrals through our partner programs).  It also includes product support (including 2 professional support incidents) and free online training for the products.

you can visit http://www.microsoft.com/web/websitespark/ for detail information

ASP.NET determines the capabilities of the browser that a user is using to browse your site by using a feature called browser capabilities. Browser capabilities are represented by the HttpBrowserCapabilities object (exposed by the Request.Browser property). For example, you can use the HttpBrowserCapabilities object to determine whether the type and version of the current browser supports a particular version of JavaScript. Or, you can use the HttpBrowserCapabilities object to determine whether the request originated from a mobile device.

The HttpBrowserCapabilities object is driven by a set of browser definition files. These files contain information about the capabilities of particular browsers. In ASP.NET 4, these browser definition files have been updated to contain information about recently introduced browsers and devices such as Google Chrome, Research in Motion BlackBerry smartphones, and Apple iPhone.

The following list shows new browser definition files:

· blackberry.browser

· chrome.browser

· Default.browser

· firefox.browser

· gateway.browser

· generic.browser

· ie.browser

· iemobile.browser

· iphone.browser

· opera.browser

· safari.browser

When a user establishes a Remote Desktop connection to the WHS this connection will remain active until the user selects “Log Off” from the Start Menu. If a user simply closes the remote desktop window when they’re finished, that username will still remain logged on.

The software running on the WHS to facilitate the Remote Desktop connection will only allow for up to two simultaneous sessions. Active and disconnected sessions are calculated in this connection limit as is the Administrator account also. The console session, however, does not count against the connection limit.

If a third attempt is made to login to the server, the dreaded “The terminal server has exceeded the maximum number of allowed connections” error will be shown to the user, and they will be unable to complete the login process. You can’t even connect to disconnect the old sessions BUT there is a way around this:

Simply click OK to the error message and wait for unto 30 seconds for the window to close then simply type the following in a Start – RUN or CMD Prompt on your client machine.

mstsc /v:00.00.00.00 /f -console
Replace 00.00.00.00 with your server’s IP Address or server name. e.g.SERVER

Type in your administrator password. This will then connect you to the Console Session on the server and allow you to remote control the machine again.

Once in Click Start, point to All Programs, point to Administrative Tools, and then  click Terminal Services Manager.

In the left hand column you should see your server name. Click on it once. Note the Users Tab in the right pane.

You should see a list of users. You need to reset the two “Disconnected” users. You can do this by right clicking the disconnected user and selecting “Reset.” You should now be able to connect with RDP again after Start – Log Off.

When logging in under this special Console session always kill the inactive sessions first, because if you get disconnected again you will have to connect your monitor, keyboard and mouse.

Only use this session to terminate the other two sessions and not for any other use.

In future when you are done with a Remote Desktop session on WHS, you should always use “Log Off” rather than disconnecting by closing the RD window with the X as this will disconnect from the session but leave it active.

It’s important to understand the difference between server-centric “AJAX” and client “pure” AJAX.

In server-centric AJAX applications, even though the application leverages asynchronous calls between client and server, the server is the one that is actually responsible for generating the necessary HTML content before providing it to the client. This leads to heavy bandwidth usage, and lack of responsiveness. In addition, the client application becomes far too reliant on the functionality of the server, and its ability to provide good markup, as opposed to simply requiring data and simple interaction.

In client AJAX applications, the communication with the server is purely for passing data back and forth. All of the rendering and state is maintained within the client environment, and the server is only brought into the picture as needed.

So, “The server should only be concerned with data, not presentation”.

In order to enable our ability to easily create dynamic UI and place the rendering process on the client, we need a way to define templates of markup that represent the UI we wish to create, and allow the runtime to instantiate them for us. This alleviates the need to write a bunch of DOM code or depend on server-rendering.

If you’ve used WebForms before, you’re already familiar with the approach many of its server controls take. You have access to a set of properties that allow you to define arbitrary templates of content, complete with HTML, server controls, and data binding expressions. This model makes it very easy to create dynamic UI that is rendered server-side [Advance Animation].

ASP.NET AJAX 4.0 introduces the ability to define templates as well, but purely client-side. Now you can create the HTML markup you want to use for representing your template, complete with HTML and data binding expressions. In this example, we’ve created an unordered list template whose content is a list item whose content is the value of the Name property of the JSON object that is bound to it. The data binding expression resembles that of WPF.

“ASP.NET AJAX is alright, but it is way too server-centric for serious client-side development…”, One of the more common misconceptions with ASP.NET AJAX is that it has always been a server-centric framework and offered little to no value for purely client-side JavaScript development. One of the primary objectives of this presentation is to show how ASP.NET AJAX as a JavaScript library has always been useable without server constraints, as well as how ASP.NET AJAX 4.0 makes that even more of a reality by adding additional support.

When some developers think of ASP.NET AJAX they implicitly associate it with WebForms, and feel like it’s very coupled to the ScriptManager and UpdatePanel server controls. While this style of development (partial rendering) in WebForms is an available option, it’s important to keep in mind that that is simply an integration point between ASP.NET AJAX and ASP.NET WebForms. If you’re already using WebForms, partial rendering provides a very easy starting point for introducing AJAX-like functionality to a web application.

That said, ASP.NET AJAX can be used outside of the context of WebForms, because it is ultimately just a collection of JavaScript files that can be referenced within a web page. It’s true that Visual Studio provides rich support for using ASP.NET AJAX, but there is no reason to treat ASP.NET AJAX any differently than any other JavaScript library (i.e. jQuery, Prototype, etc.)

Taking a pragmatic look at the existing ASP.NET AJAX release, we recognize that there are some things missing from it that are really necessary to begin doing any serious client-side web development with it.

There needs to be a stronger offering in terms of client-side controls, which ideally would also provide the same level of templating and data binding that the server controls in WebForms provide. In addition, because JavaScript is a client technology, communication between the server needs to be extremely easy, such that developing with JavaScript, and taking on the tax of an additional tier, becomes simple enough to warrant the benefits it provides without overloading the time it takes to create.

Finally, ASP.NET AJAX really needs to become modular in the sense that developers can pick and choose what pieces of the framework they want to use, or need for that matter.

The power of writing declarative code (versus imperative code) is that the developer focuses more on expressing the “WHAT needs to be done” rather than “HOW it is to be done.” This is important because it leads to many benefits. One of the benefits is that the impedance mismatch that happens between the problem a developer needs to solve, and how he solves it becomes less and less. Currently, expressing solutions in an imperative way does not allow a developer to express the true intent of his code.

The only advantage of a declarative programming model is that the compiler and runtime can be more liberal with the changes it implements in order to make the code as efficient as possible. This is due to the fact that the code is no longer directly tied to the implementation of the underlying algorithm like it is when using imperative code.

the new c# 4.0 will have much improvement on declarative code, so not miss it!