Atlas Project

We are now well into the final RTM milestone of the ASP.NET 2.0 and Visual Web Developer 2005 release. Having reached our ZBB (Zero Bug Bounce), we are now locked down on our feature set, and we’re focusing on the final quality, performance, and reliability push.

 

At the same time, we have started to work on our next release. One area we’ve been looking at for a while is the growing popularity of richer user experiences in browsers, through AJAX (Asynchronous Javascript and XML)-style programming.

 

All of the pieces of AJAX – DHTML, JScript, and XMLHTTP – have been available in Internet Explorer for some time, and Outlook Web Access has used these techniques to deliver a great browser experience since 1998. In ASP.NET 2.0, we have also made it easier to write AJAX-style applications for any browser using asynchronous callbacks, and we use them in several of our built-in controls.

 

Recently, however, the technologies used by AJAX have become broadly available in all browsers, and use of this model for rich web applications has really taken flight. There are a number of high-profile new AJAX-style websites out there today, including a number by Google, as well as sites like A9 and Flickr. Microsoft will also have more sites that use this technology out there soon – check out Start.com and the MSN Virtual Earth project for examples.

 

The popularity of AJAX shows the growing demand for richer user experiences over the web. However, developing and debugging AJAX-style web applications is a very difficult task today. To write a rich web UI, you have to know a great deal of DHTML and JavaScript, and have a strong understanding of all the differences and design details of various browsers. There are very few tools to help your design or build these applications easily. Finally, debugging and testing these applications can be very tricky.

 

What we’ve set out to do is to make it dramatically easier for anyone to build AJAX-style web applications that deliver rich, interactive, and personalized experiences. Developers should be able to build these applications without great expertise in client scripting; they should be able to integrate their browser UI seamlessly with the rest of their applications; and they should be able to develop and debug these applications with ease.

 

For this work, we’ve been working on a new project on our team, codenamed “Atlas”. Our goal is to produce a developer preview release on top of ASP.NET 2.0 for the PDC this September, and then have a website where we can keep updating the core bits, publishing samples, and building an active community around it.

 

Here are some of the pieces of Atlas that we are going to be delivering over time:

 

 

Atlas Client Script Framework

 

The Atlas Client Script Framework is an extensible, object-oriented 100% JavaScript client framework that allows you to easily build AJAX-style browser applications with rich UI and connectivity to web services. With Atlas, you can write web applications that use a lot of DHTML, Javascript, and XMLHTTP, without having to be an expert in any of these technologies.

 

The Atlas Client Script Framework will work on all modern browsers, and with any web server. It also won’t require any client installation at all – to use it, you can simply include references to the right script files in your page.

 

The Atlas Client Script Framework will include the following components:

o        An extensible core framework that adds features to JavaScript such as lifetime management, inheritance, multicast event handlers, and interfaces

o        A base class library for common features such as rich string manipulation, timers, and running tasks

o        A UI framework for attaching dynamic behaviors to HTML in a cross-browser way

o        A network stack to simplify server connectivity and access to web services

o        A set of controls for rich UI, such as auto-complete textboxes, popup panels, animation, and drag and drop

o        A browser compatibility layer to address scripting behavior differences between browsers.

 

 

ASP.NET Server Controls for Atlas

 

For ASP.NET applications, we are planning on building a new set of AJAX-style ASP.NET Server Controls, and enhancing our existing ASP.NET page framework and controls, to support the Atlas Client Script Framework.

 

ASP.NET 2.0 includes a new feature, called asynchronous client callbacks, that makes it easy to build ASP.NET pages that update their content from the server without requiring a page roundtrip. Asynchronous client callbacks wrap XMLHTTP, and work on a variety of browsers. ASP.NET itself includes several controls that use callbacks, including client-side paging and sorting in the GridView and DetailsView controls, and supporting virtual lists of items in the TreeView control. You can learn more about callbacks on Bertrand Le Roy’s blog.

 

The Atlas Client Script Framework will fully support ASP.NET 2.0 callbacks, but we’re planning on enriching the level of integration between the browser and the server much further. For example, you will be able to data bind Atlas client controls to ASP.NET data source controls on the server, and you’ll be able to control personalization features of web parts pages asynchronously from the client.

 

 

ASP.NET Web Services Integration

 

Like any client application, an AJAX-style web application will usually need to access functionality on the web server. The model for connecting to the server for Atlas applications is the same as for the rest of the platform – through the use of Web services.

 

With ASP.NET Web Services Integration, Atlas applications will be able to access any ASP.NET-hosted ASMX or Indigo service directly through the Atlas Client Script Framework, on any browser that supports XMLHTTP. The framework will automatically handle proxy generation, and object serialization to and from script. With web services integration, you can use a single programming model to write your services, and use them in any application, from browser-based sites to full smart client applications.

 

 

 ASP.NET Building Block Services for Atlas

 

With ASP.NET 2.0, we’ve built a rich set of building block services that make it incredibly easy to build powerful, personalized web applications. These building blocks dramatically reduce the amount of code you have to write for common web application scenarios, such as managing users, authorizing users by role, and storing profiles and personalized data.

 

With Atlas, we’ll make these accessible as web services that can be used from the client framework in the browser or from any client application. For example, if you are building a website that shows a list of to-do items for the user, you can use the ASP.NET Profile service to store them in the user’s profile on the server. These items will then be accessible even as the user roams from one machine to another.

 

Services we will provide include the following (all based on the ASP.NET V2.0 implementations):

 

-          Profile: Store per-user data on the server.

-          UI Personalization: Store personalized UI settings on the server.

-          Authentication: Authenticate users.

-          Roles: Authorize user tasks and show different UI based on the user’s roles.

 

Because these building blocks are server based, you can use the same security model as for accessing the rest of the site. These services also won’t require any client download – just reference the script proxy from the browser.

 

All of our ASP.NET 2.0 Building Block Services are pluggable at the back-end using a common provider model extensibility pattern. We provide built-in providers that let you use a SQL Server database or Active Directory as a store, but you can easily plug in your own. For example, if you want to store user profiles in a centralized cloud rather than on your own database server, you can simply plug in a different provider – the choice is yours. 

 

 

Client Building Block Services

 

In addition to DHTML, JScript, and XMLHTTP, we’re looking at additional services that allow websites to harness the power of the client to deliver an enriched experience.

 

The local browser cache is an example of such a service. When enabled, websites can store content in that cache and later retrieve it efficiently. But there’s no API from the browser to store data in the cache, and applications like Google Maps or OWA have to go through hoops to generate unique URLs so that the browser will cache the server response. With Atlas, we plan on providing programmable access to a local store/cache, so that applications can locally cache data easily, efficiently and securely.

 

Integration with other applications is another new dimension of a rich web experience. For example, when a user browses an auction site and bids on an item, they can see when the auction ends, but how easily can they integrate that event into their personal calendar application? With Atlas, we are also looking to provide a set of client-side building block services, and a model for how websites can securely publish connection points for those services. When the user selects “Add to Calendar”, the browser can call the connection point to get the calendar data, and pass it onto the local calendar application. The page doesn’t get to download or run its own code or initiate the action, so it’s safer than ActiveX.

 

 

Next Steps

 

As we move further along, more pieces of the story will emerge. In parallel, we are already working on our next release of development and debugging tools, so that we can deliver a great development experience for these type of rich web applications.

 

One question you may have is how Atlas relates to Avalon and smart clients.

 

We see Atlas as the best way to write a whole new generation of richer, more interactive, more personalized experiences in browser applications.  Avalon is the next generation presentation model for Microsoft, and will let you build the richest user experiences on the Windows platform. Avalon will deliver phenomenal graphical experiences that use the latest in media integration and hardware acceleration. And Avalon will also let you provide persistent, immersive experiences that go beyond the browser.

 

Of course, when you’re building Avalon applications, you can reuse the programming model investments you make today with ASP.NET and Atlas. For example, the ASP.Net Building Block Services and Client Building Block Services will also be accessible from any Avalon client. This model gives you a smooth path to the next generation of applications.

 

Stay tuned here to hear more about our plans for Atlas and ASP.NET V.Next. And let us know your thoughts – Are you considering building richer AJAX-style web applications? What would you like to see in Atlas?  You can post here on the blog, or send your comments to our feedback to our team alias at atlas@microsoft.com.

 

Thanks,

 

Web Platform and Tools Team

 

P.S. Some of you may be wondering how we chose the name Atlas.  We’ve used several names related to Saturn for projects owned by our team.  Saturn itself was the codename for ASP.NET Web Matrix, Cassini was the sample web server for hosting ASP.NET, and Calypso was the name for our community website at www.asp.net. And we thought Atlas would be a nice name for the roadmap to the next generation of rich, personalized web applications.

 

P.P.S. To learn even more come to the PDC this September

69 Comments

  • Awesome! - You did it again ;)



    Did you take a look at the AJAX.NET (www.schwarz-interactive.de) implementation that recently went open source? - It really has some niffty features such as DataSet support in the client etc. which would be great to have in ASP.NET V2 as well!!

  • This is great! You guys rock! This should definately take ASP.NET to the next level!

  • I agree with Marc, AJAX.NET is very cool and extremely useful. We use it on some of our projects.

  • Cool stuff! But I'm fuzzy - will this be part of the next version of the .NET framework, or an add-on to 2.0?

  • Looking forward to that. It'll be technology to use in the future.

  • Thanks for the great new tools Scott, you make our lives as developers much more rewarding.

  • How well will this work for non-IE browsers and other (non-pc) platforms? It is pretty much useless otherwise.

  • Atlas will work with all modern browsers. It will also work on non-Windows platforms.

  • Very nice..Waiting to see and to experiment with!

  • check out AJAX.NET

  • Will this system be open to developers who know what they're doing? Who know how they want to render in browser X and want to use their own JScripts.



    The uplevel / downlevel dichotomy in ASP.NET 1.x forced many to roll their own. (Cause downlevel is not a serious contender.)



    I hope this won't be similar. We need to be able to make it do what we want, including (probably) tailoring the rendering for different browsers.

  • Great! and hopefully you can include some improved js intellisense in VS.Next

  • Hi Mike,



    That is definitely our goal (making it very flexible and extensible for advanced developers). The core framework will provide tons of customization opportunities. It is also cross-plat and cross-browser by default.



    Hope this helps,



    Scott

  • Scott,



    Very cool. You guys should definitely take a look at some of the kits already in this space. The one with the scope nearest to what you're trying to build is probably the Dojo Toolkit (dojotoolkit.org).



    One thing that concerns me however, is when you say that developers should be able to use this technology without really understanding it (I paraphrase :-)). You should be careful with that. I also have a good deal of experience with ASP.Net and DHTML and as a previous poster said, the server controls that shipped with ASP.Net 1.0 were a complete no-go because they weren't - in a word - webby.



    They did not build on the fundamentals of modern web development: structural markup and CSS for presentation, gracefully improving when the right technologies (CSS, DOM) were available. Instead, they tried to detect browsers on the server and send two completely different sets of markup to the client, creating a maintenance nightmare.



    I think the reason this was done was the same reason that is being presented here: to make it really easy to get something that jumps and spins onto the page for people that didn't really understand how that's accomplished.



    Most technologies MSFT have created recently that really succeed do so because of their clarity, transparency, and consistency -- not because of their drag-n-drop-ability.



    Take, for example the .NET BCL. By all means, probably more complex than VB Control or ATL. But wildly popular and successful. Why? I think because once people understand how .NET works at a high level and have the fundamental concepts, they can crack that BCL open and peer all the way down to the very bottom and it all makes sense. It's all self-consistent and plays by the same rules.



    Do the same for DHTML. Build on top of the foundation of the real web, not a new one that you layer on top of the real one. That way, when developers are ready to customize and extend those great AJAX tools you give them -- they won't be shocked to find that internally, they're completely different beasts. There will be a smooth learning curve all the way down to the very core. I think that is the way to make this a successful project in the long term.

  • Thanks to Web Platform and Tools Team.You r doing great things for microsoft developer community.



  • Atlas appears to have a very rich feature-set, compared to competitors, and developer previews are nice.



    How about creating a SUPPORTED "reduced feature version"? Then developers can start using that (and DEPLOY). If you release a "install at your own risk and if anything fails your on your own" version, we most certainly can’t afford to invest much time in this now. Later, when you release the full version, we may already have invested too much time in competing libraries.

  • I've used AJAX for a few web apps previously but they were always limited to intranets because they relied on the XMLHTTP ActiveX object and so the user's IE security settings had to allow ActiveX scripting. Won't this still be an issue for Atlas?

  • "The Atlas Client Script Framework will work on all modern browsers" - tested based on capability, rather than user_agent, I'd hope?



    That should be a question I wouldn't even have to ask, but, well... after asp.net 1.0...

  • Hi,



    Sort of expanding on Aaron's comments is some basic accessibility issues.



    For example, will the .NET controls for Ajax provide some alternative when JavaScript is disabled by users (e.g. round tripping), or will that need to be developed by web developers instead (I can imagine it quite tricky to provide such an alternative out of the box).



    Other accessibility issues that people need to consider are the impacts to screen reader users when content is updated somewhere on the page (causes some screen readers to jump to the updated content, thoroughly diorienting the user).



    I guess what I am saying is that Ajax applications, while very cool and potentially extremely useful, somehow need to be developed with care.



    Will .NET be providing any information, controls or something else to help in this area?

  • I think, explorer's developers can help you. If they implement the library of javascript procedures into universal global library placed into internet server then many problems for asp.net go away. I suppose it will cool features when all explorer's developers will use shared common library of JS with good documentation and description. You suppose that Atlas must to provide rich UI and easy implementing of DHTML for user but it will better if that client side (any rich UI editor need a lot of JS code) will borned from explorer side. I hope we have poore web explorer still, we will try to save state our pages by hide information posted around server but we forgot that explorer is for it. DOM was first step to solve task about less loading of server from a big quantity of bytes transmitted between client and server side, so i hope in Atlas your team will continue this way and may be Opera, NS, FireFox, IE and so on will try to find share variant of making internet client browsers. Idea is simple - shared JS library has in xml file for example or into web service the information about current version. When the user start his explorer then explorer check the global library and upload new adds if it is. ASP.NET developers use the global library for their projects and they don't think about is it library in user side or not.

    Sincerely, LukCAD.

  • I have to agree with Aaron - don't kill this by making it so simple that my grandmother could use it.



    If it's functional, extensible and compliant it will be a welcome addition to my toolbox.



    If it generates or encourages bad code just to make things easier, I will avoid it like the plague.

  • How about creating a supported "reduce feature version" ?

  • Hello.



    I am 31 years old. And code its my life. I am artist and coder, profesional.

    AJAX its a cool buzzword, but the feel of most .NET coded webpages its __WRONG__ befeuse feel obstructive to player desieres. More "this page has his own mind" will make pages feel much less responsive, much more crappy. And this will be the result of giving ATLAS to some people out here.



    This its not a tecnical problem, more than a human problem. How to solve?. Maybe Microsoft sould avoid giving powers that sould be really user powers. Sould create a imaginary border, and distribute powers clearly.



    Yet another question:



    I feel really need to jump to java. But I dont really like Java. Its too verbose. I may jump to .NET but I want to continue using Linux. Can be Microsoft glad enough to give rights-to-use to the Mono project so will be __safe__ to learn .NET? I dont want to waste YEARS of learning to .NET then MS banning my servers runtimes.. If MS dont give Mono a happy "good luck!" and friendship, I will not learn .NET



    Thanks!



    --Tei



  • Hi Scott,



    You already have some very positive comments re: Atlas, and I also think that this is a *very* important aspect that needs to be factored into general ASP.NET development asap. Integrating "real" client side functionality from the server via Atlas (ie. roles, personalisation etc...) will position ASP.NET on the forefront of an imminent wave (IMHO). Any chance of a "Component download" add-in for V2.0 of ASP.NET instead of waiting for a next release?

  • Why not an XForms implementation?

  • Hi Paul,



    Our plans are to have a component download that runs on top of ASP.NET V2.0 this fall (and on going) as part of the tech-preview. So you will be able to take advantage of it pm top of Whidbey.



    Hope this helps,



    Scott

  • Hello Scott.

    Is it possible to get Atlas betta version for testing?

    Sincerely, LukCAD

  • This is slightly offtopic, but here goes anyway... will Visual Web Developer 2005 fix the problems I've heard about it treating Firefox et. al. as downlevel browsers?

  • I've come a cropper using AJAX in an intranet-environment with IE6.0.2600 and IE6.0.2800 clients when accessing a W2K IIS6 server. AJAX requests take ages to return their results. Sometimes they work fine for a few requests and then fail, othertimes they fail immediately.



    Using the same (very simple script) on a client machine that previously failed having updated via XP SP2 to IE6.0.2900 works fine.



    Using the same script on a previously failing client when served from a W2K IIS5.0 or WinXP IIS5.1 server also works fine.



    it's specifically W2K IIS6 and pre-IE6.0.2900 browsers. Infuriating!

  • Hi Tek,



    ASP.NET 2.0 treats Firefox, Safari and Opera as up-level browsers now.



    Hope this helps,



    Scott

  • Will Atlas be available only for servers running Windows Server? Or can you have it running from Apache or any other server also?

  • Hi Sjonk,



    Different pieces of Atlas can be used different places. The core client-side jscript framework could be used with any web-server.



    Thanks,



    Scott

  • it should be completely transparent: event handlers should be called via XmlHttp and on the server one should be able to write:



    button1_OnClick (blah)

    {

    textbox1.Text = "hello world";

    }



    and the property changes should be serialized into a message returned (in the XmlHttp response) to the client to update the properties on the page.

  • Thanks a lot, Michael.

    I will soon rebuild all my lybraries to include yours Ajax.dll (5.6.3.4). But say me, is it core of Atlas?

    Sincerely, LukCAD

  • Please make sure that if you loop requests to the server the memory does not leak. The Web Service behaviour and AJAX were useless for continuously running dhtml applications

  • Scott,



    Great idea. Our application has been doing this sort of thing for over 3 years now and we have built a whole host of libraries to provide the necessary dynamism that we need on the client. Right now, these are limited to IE versions only, but off-late we are getting requests to support other browsers too.



    I will be very interested to take part in any Beta programs that you guys are planning to evaluate this model and provide feedback.

  • Hello Scott,



    It's possible the next release of the Visual Studio .NET 2005 (November 2005), contain the Atlas incorporated in Web Application Projects?



    Thank you very much,

  • Boy!

    There sure are a lot of people promoting their "wares"! I like Bertrand's work the best, especially the server-side ECMAObject creation - more Service Oriented. In fact, I even "Backported" the callback script interfaces to ASP.NET 1.1. "just for fun". Good work! Looking forward to the preview.

  • Ever since the AdaptivePath folks coined AJAX, a lot of us old-time DHTML/XMLTTP programmers have remarked about how funny it was that all this time, we never thought of giving this marriage of technologies a cool nickname.



    You mean THAT's what it took to get it noticed?



    What about those instantly refreshing HTML objects? What about the disappearance of "white flash" from old-style page re-posts? Where was the love then, we ask?



    Oh, well. Better late then never....

  • We tried an AJAX approach with a TreeView (asynchronous downloading of tree nodes) a couple of years ago. Unfortunately, we used the MS non supported WebService htc. It turns out, that htc swamped the clients proxy server with many open http connections. When the client maxed out their allowable number of http connections, the WebServices htc quit working. In our experience, BE SURE to test this well with proxy servers and automatically LIMIT the number of open connections so that this limitation is avoided. Most proxy server setups are for typical yahoo style web pages, and are not setup for many simultaneous http requests that AJAX can generate. Just my 2 cents; I'm very glad MS is beginning to support this .Net.

  • This sounds quite a bit like the product Dart sells called PowerWEB LiveControls for ASP.NET at www.dart.com. Just thought I would mention that this type of technology with rich UI in ASP.NET is already available.

    Thanks,

    Alex

  • Absolutly great.



    We still live in a world where we have to dream about having the exe apps abilitys in a web app, but those days migth be nearing its end.

  • I remember wishing I had the time to implement the asyn calls back in 2000, but it was too hard to sell to clients/bosses from a cost benefit argument; but if there's actually a framework to work with though, that would be something!!! I was hoping for a 2 part solution;

    1 for simple bound field/action call backs that would spit all the JS infrastucture code so you could attach a client side event such as keydown on a text box to a serverside function without writing a line of JS (not even an .innertext replace that should all be handled in this model)



    and secondly a more advanced model that would lay down some of the plumbing and let you fill in the guts with your own JS so that if you needed to implement custom types of behaviors you wouldn't be locked into the limitations of the 'easy' aforementioned model. I'm glad it's finally happening, we may have elegant UI's on the web yet!!!

  • How is Atlas going to be integrated into the Office forms server?



    Will PSS support ASP.NET applications built with Atlas?



    Will PSS support ASP.NET 2.0 Web Parts that incorporate Atlas-based functionality?

  • Hi Scott, thanks for the info. The ATLAS framework should implement something similar to the AJAX NET library from Michael. I never saw such an easy implementation of AJAX for the .NET Framework. Is there any public beta scheduled?

  • This is seriously cool stuff - I'm writing a cms right now where I really want to use these technologies, but will have to wait until ASP.NET 2.0 comes out. Is Microsoft also working on a time machine?

  • This is amazing, i have been looking to do a lot of things that you mention as Atlas features recently for an upcoming project.



    I simply cannot wait :)

  • One of the classic problem is localizing javascript strings. The

    <tt>

    alert("<asp:localize runat=server ...>");

    </tt>

    is not robust, a localized using " or ' or ??? can break it.



    The other issue is localization of the display of Dates and Numbers. Javascript Date.toString() does not respect user preferences. Similarly, there is no ability to format in Javascript:



    1233567.89 as

    1,233,567.89 or

    1.233.567,89 or

    12,33,567.89 (India)



    Will Atlas provides syncronization with the culture of the page?

  • Hi to all of the ATLAS project: what we need is a data access layer for javascript client-side. I saw a lot of very good implementations like the AJAX library for .NET from Michael Schwartz. Also, what I saw was some cool controls at dart.com.

  • Is there a library form Michael that will be supported on ASP.NET 2.0?

  • We want to have AJAX.NET in the new Atlas Framework!!! Is there any roadmap or beta version available? We love the way AJAX.NET is working: simple attribute usage and fast working. PLeas look at the demo page from Michael.

  • I keep thinking why is the focus still on Java Script for client side stuff. Why can't there be a C# script created. I mean people seem to be asking for a compiled Java Script. C# is already compiled - so why not use that? Do you see any reason why an Interpreted version of C# could not be created? C# on the client for smart clients and IE seems natural to me. For that matter, any of the .Net languages should be supported instead of just allowing Java script. Is there any plans for this? Ideas? TIA

    -- wjs

  • Love it and can't wait for more

  • Atlas sounds awesome, but so did ClickOnce and the SQL Report Viewer. MS claimed they would support other browsers with those technologies too.

    Try clickonce with any browser other than IE. Try the report viewer with any browser than IE. If that's support, I don't even want to guess what will happen with Atlas.

  • Does Atlas disregard JavaScript positioning?
    Style.left and style.top work only sometimes, both in a declarative div after it has been successfuly dragged and a div dynamically created using Atlas Controls..Has anyone else seen this problem?

  • Hi Frank,

    Atlas shouldn't impact styling or CSS. The only thing I could think of is whether you have another CSS stylesheet in your project or sample that might be overwriting these settings (CSS can be finiky when you have multiple rules defined).

    Hope this helps,

    Scott

  • I forgot to add the particulars: I have an item .. do a before and after positioning. The before drag/drop works just fine.. the div is positioned exactly where it should be. After the drag drop, the positioning fails.

  • Hi Dwight,

    Atlas doesn't change your CSS and does absolutely work with DHTML. I will try and follow up in your forum post to figure out what problem you might be happening.

    Thanks,

    Scott

  • We have started relying heavily on AJAX to improve the functionality of our web UI's. Since you're looking for suggestions, I will oblige. I think an ASP.NET server control you can associate with a BackgroundWorker would be extremely useful for creating effective web UI's for long-running tasks. It can be used to do a vareity of client updates including progress and status without traditional postbacks. Right now we use timed asynchronous postbacks to check on our threads. It took a lot of messy wiring to get that working smoothly. Even if it just approximates two-way communication with timed requests, a simple control framework around that would really improve the platform for everybody.

  • AjaxPro is a real nice framework out there. Waiting for Atlas to come out of beta.

  • Visual Studio 2005 VML ... Can I use VML in an Atlas project? I can not get a build with VML tags in an Atlas webpage .. either VB or C##

  • Hi Murali,

    Could you send me an email (scottgu@microsoft.com) that contains the details of the problem? I'll then loop you in with someone on the ASP.NET AJAX team who can help.

    Thanks,

    Scott

  • Thanks Scott I am sending you my sample project right away.

  • Hi Paulo,

    You can download the Atlas Control Toolkit here: http://www.codeplex.com/AtlasControlToolkit

    Hope this helps,

    Scott

  • Hi Scott,

    The link that you send to me is from the atlas toolkit version 1.0.61106, and i want the version 2.0.50727.
    Can you give me the correct link for it?

    Thanks.

  • Hi baiguai,

    Can you send me an email with details of the problem you are seeing? I'll then loop in some folks who can help.

    Thanks,

    Scott

  • On July 1 Charlie Farley posted a problem with IIS6 and IE6 versions prior to 6.0.2900 and I don't see a response. Do you have any further information regarding the problem?

  • Hi Scott,

    First thanks for your simple instructional video on this it was the eye opener that got me going on it and so far its awesome.

    One thing that bugs me though is with the Model of (MasterPage>Form>WebControl) how can I have a user go from form to form with out the screen blinking?

    Is there a trick with atlas to to do this?

  • Hi Scott,

    Some versions of IE6 have a bug where they don't handle GZIP'd script files correctly. The RTM version of ASP.NET AJAX works around this by explictly not compressing files for these versions of IE.

    With the current RC you can work around the issue by turning off script compression for all browsers. This can be configured in the web.config file.

    Thanks,

    Scott

Comments have been disabled for this content.