October 2005 - Posts
Quite some time ago, I talked about generics. If you have ever used C++, you know what these are and why they are cool. This article gives a good description about the use of generics and how to use them.
I post on this with every release, but I'll post something about the latest blog entry on it. The easiest way to remove previous versions of Visual Studio 2005 is to use the Uninstall tool. You can find it through the page linked below. This page also has some additional tools to help troubleshoot problems as well as a tool that can be used to remove WinFX runtime components. If you need any assistance in installing, please let me know.
MSDN has changed a little bit with the release of Visual Studio 2005. When you go to the subscriptions page (
http://msdn.microsoft.com/subscriptions/), there will be two links MSDN Universal Subscriptions and MSDN Team Developer Subscriptions. If you click on the Universal Subscriptions you will get a Benefit Expired error. This is because your account has been transitioned to MSDN Premium with Team Developer. This means you can only download the Team Developer version of Visual Studio 2005. You won't have access to any of the testing or architect features.
They released it today on MSDN earlier than the original 11/7 launch date. Here is some more information. The download site is of course slammed, so it may take some time to get it.
Atlas exposes a number of .NET types through JavaScript. This allows you to use familiar calls to do routine tasks (i.e: stringBuilder, etc.). This web page lets you browse through some of the scripts.
I have to say there has been a heap of online training and videos for ASP.NET 2.0. The link below has even more. The topics covered are Simplified Data Access with ASP.NET (covers the new data controls, etc.) and Getting Started with Visual Web Developer 2005 Express Edition. The come in both C# and Visual Basic (for Marcus) varieties. If you are interested in learning more, give one of them a try.
Compilation and Publishing in ASP.NET 2.0 is completely different than in ASP.NET 1.1. In ASP.NET 1.1, whether you debugged the code or ran it from a server, all of the .cs files were compiled into a single dll (i.e.: thrifty.web.dll) and the markup (.aspx and .ascx) remained seperate. This could often lead to problems if you declared a control in the markup but then didn't have a coresponding reference in the .cs file. All of this has changed.
First and foremost, when you click Build Web Site, it does not compile all of the .cs files into a single dll. It only validates that the code is syntactically correct. It will validate the .cs files as well as the .aspx and .ascx files. When you run it through the debugger or you use xcopy deployment directly against the files in your web project, it uses dynamic compilation to run the web site. This means that if you change a .cs file, the next time that file is hit in a web browser, it will compile it on the fly. This can be cool for some for development, but not ideal for deployment.
So when you want to deploy the web site, you click Publish Web Site. You can also do this using the new aspnet_compiler.exe and point it to a solution file (allowing for automated builds, etc.). The Publish Web Site dialog will prompt you for a location. This can be a file path, a web site address, or ftp site. It also has three different options:
- Allow this precompiled site to be updatable
- Use fixed naming and single page assemblies
- Enable strong naming on precompiled assemblies
The Allow this precompiled site to be update option when checked leaves all of the .aspx and .ascx files alone. This way they can be changed by an external tool (i.e.: Rhythmyx). When it is unchecked, it compiles the entire site including .aspx and .ascx files into a single dll or multiple dlls.
The Use fixed naming and single page assemblies option tells the compiler to use the same names for the dlls it creates every time it compiles. It also will make the compiler create seperate dlls for every page and control on the site. This will allow for indiviudal controls to be updated without affecting any of the other ones. The filename format for a particular dll will be App_web_<filename>.<random four byte hex string>.dll. So the filename for the LocationTime control would look like this, App_web_locationtime.ascx.2ce845ef.dll. The random four byte hex string is supposedly the same every time you compile. It also seems to use the same string at each directory level. When unchecked there is no guarantee what the filenames will be in the dlls and entire directories will be grouped into the same dlls.
Enable Strong Naming on Precompiled Assemblies is basically the same as specifynig a key in the assemblyinfo.cs in ASP.NET 1.1.
As described above, there are a ton of differences in compiling with ASP.NET 2.0. Hopefully this will make it easier to understand.
If you have to do a complete application validation in order to debug Thrifty.com, plan on waiting a while. It typically takes about a minute to compile. Need to publish the web site somewhere to deploy it? Plan on waiting even longer.
The web site administration tool is a web site that can be used to change settings in your web.config and machine.config. Anyone with write access to those files prior to beta 2 could use the tool. Now they have changed it so that the tool can only be accessed locally. This is a bad time, since it would have made it a lot easier for us to make these kind of changes ourselves.
Rather than leave something that worked well alone that was quite simple, Microsoft has decided to change where it gets the URL for a dynamic web reference. Web Applications and everything else (class libraries, windows forms apps, etc.) handle proxies totally differently than in 1.1.
Web References in ASP.NET applications sort of look the same. The biggest difference in there is no reference.cs any more (that is dynamically generated at runtime). Secondly, web references have been moved from the Web References folder to the App_WebReferences folder. There is no setting for static/dynamic. When you set the URL for a web reference, it automatically places a line in the web.config. This line can easily be moved to the machine.config and it will behave just like a 1.1 web reference proxy.
Now for everything else. Oh boy. Well, for the most part it behaves a lot like 1.1. It still has static / dynamic and a reference.cs. However, they added support for the new Settings.settings file available to class libraries and windows forms applications. So in order to account for this, they moved it into a section that complies more with the new settings file.
To do this they have a new configSection called applicationSettings (not to be confused with appSettings). Inside this section it creates a custom section for the assembly you are using called a ClientSettingsSection. It looks kind of like this when registered in the configSections element.
<sectionGroup name="applicationSettings"
type="System.Configuration.ApplicationSettingsGroup,
System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="Thrifty.Components.Web.Properties.Settings"
type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089"
requirePermission="false" />
</sectionGroup>
Now, you want to set those URLs for the web services. Well the new schema for that looks like this.
<applicationSettings>
<Thrifty.Components.Web.Properties.Settings>
<setting name="Thrifty_Components_Web_SupportWebService_Support"
serializeAs="String">
<value>http://172.16.24.150/cmt/private/Support.asmx</value>
</setting>
</Thrifty.Components.Web.Properties.Settings>
</applicationSettings>
Notice the name attribute in the setting element. This is the name of the web refenence including a namespace using underscores instead of periods. This corresponds to the following code in reference.cs. Notice it maps to the setting value set in the element.
this.Url =
global::Thrifty.Components.Web.Properties.Settings.Default
.Thrifty_Components_Web_SupportWebService_Support;
The value element specifies the URL to the web service. By default it autogenerates these elements in your app.config in the assembly.
This is currently the only way I know of specifying URLs to a web service without custom coding. There may be some new best practice that we don't yet know of.
For a product like this finally coming out, we certainly cannot miss it. The Visual Studio 2005 Launch Event is November 15th from 1:00 - 5:00 at AMC SouthRoads 20. It looks like the SQL Server Launch Event is in the morning, so we may even attend that. It looks like they are giving away free copies of Visual Studio 2005 professional and Microsoft SQL Server 2005 Standard (maybe the stuff is ebayable).
If you are interested in going, go to the URL below.
Kevin beat me to finding this new feature that Scott Guthrie just posted on, but it is very cool. If you place a file called App_Offline.htm in the root of your web application, it will shut down all incoming requests into the web server and not return any dynamic pages. This is a great feature when you want to pull your server down for maintenance.
This seems to be a fix for the "Unable to Refresh Folder" error when opening up a web probject in VS2003. It seems that I fixed it last time by deleting the contents of the Document And Settings\<Username>\VSWebCache folder.
So you have heard about this new atlas crap and you are wondering how it all works. It turns out in Atlas, there are a lot of different ways to do the same thing. What I am going to talk about today, is how you can call a web service. Atlas uses something called json (JavaScript Object Notation) to describe how objects are passed via web services, etc. To use a web service with Atlas, a different handler is used to generate the proxy toe be used by the javascript. So in all the examples, you will see this in the web.config.
<httpHandlers>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx"
type="Microsoft.Web.Services.ScriptHandlerFactory"
validate="false"/>
</httpHandlers>
This allows the json representation for that web service method to be returned and included by a script line like this.
<script type="text/javascript" language="JavaScript" src="SimpleService.asmx/js">
When you view the contents of the script, you will get something like the following.
Type.registerNamespace('Quickstart.Samples'); Quickstart.Samples.SimpleService =
{ path: "/quickstart/atlas/samples/services/SimpleService.asmx",
EchoString:function(s,onMethodComplete, onMethodTimeout)
{return Web.Net.ServiceMethodRequest.callMethod(this.path,
"EchoString",{s:s}, onMethodComplete, onMethodTimeout); } }
This basically makes calls into the Atlas core javascript libaries which know how to call a web service asynchronously. The atlas core libraries are included by these lines.
<atlas:Script ID="Script1" runat="server" Path="~/ScriptLibrary/AtlasCompat.js"
Browser="Mozilla" />
<atlas:Script ID="Script2" runat="server" Path="~/ScriptLibrary/AtlasCompat.js"
Browser="Firefox" />
<atlas:Script ID="Script3" runat="server"
Path="~/ScriptLibrary/AtlasRuntime.js"/>
Once you have all of that you can just write a javascript method that calls the web service, passing it the input values, an event to call on completion and timeout.
requestSimpleService = Quickstart.Samples.SimpleService.EchoString(
"SomeText", //params
OnComplete, //Complete event
OnTimeout //Timeout event
);
That really is all that is to it. If you want to see a working example, try the link below.
If you have not installed the templates yet for it, be sure and do so at the link below.
If you don't feel like installing Visual Studio but want to try out some of the new features, try using a v-lab. These virtual labs effectively allow you to remote into a machine to try out some of the features in Visual Studio 2005.
More Posts
Next page »