Here is a tip I picked up at the MVP summit from ASP.NET team member Simon Calvert.
You can place a user control file in App_Code, as long as the .ascx uses inline code. The user control will compile into the App_Code assembly. Instead of using LoadControl with a virtual path parameter, you can use the overloaded version accepting a Type parameter.
As an example, here is the contents of MyUserControl.ascx. Place the file in the App_Code directory.
<%@ Control Language="C#" ClassName="MyUserControl" %>
<script runat="server">
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
Label.Text = "Bonjour!";
}
</script>
<asp:Label runat="server" ID="Label" />
Here is the code for a web form that dynamically loads the control.
using System;
using ASP;
public partial class _Default : System.Web.UI.Page
{
protected override void OnInit(EventArgs e)
{
base.OnInit(e);
MyUserControl c;
c = LoadControl(typeof(MyUserControl), null)
as MyUserControl;
if (c != null)
{
Controls.Add(c);
}
}
}
Note: No @ Reference directive was required in the .aspx file.
Why is this interesting?
I was conversing with Shawn Wildermuth, and Shawn is unhappy with the solutions needed to make types visible in the ASP.NET 2.0 compilation model, solutions like using @ Reference and stubs. Shawn is not the only one. The above solution is easy if you don’t mind using the App_Code directory. The user control type will be visible to both the App_Code assembly and all web form assemblies.
What language is the following code snippet using?
var person = new
{
Name = "Steve",
JobTitle = "National Assurance Orchestrator"
};
A) JavaScript
B) C# 3.0
C) COBOL.NET with WinFS extensions.
D) None of the above
For hints, see Steve Maine’s excellent post “On JSON” (JavaScript Object Notation), and Abhinaba’s informative rant “C# 3.0: I do not like Anonymous types”.
This week is Microsoft's MVP Summit in Seattle. I’m looking forward to seeing the city of Seattle, home of the National UFO Reporting Center. I hear Microsoft has a branch office or something nearby, too. I'm also looking forward to meeting many people I only know electronically, and cornering members of the MSBuild team. I want information, and not about aliens.
In the middle of October, I’ll be speaking at VSLive! 2005, in Orlando, Florida. The topic will be debugging with Visual Studio 2005, and I’m in the midst of preparing a pretty cool demo, complete with bugs. It’s not often that you want to start off a presentation with an exception.
The .NET Rocks! Road Show is making a couple stops in my neighborhood (Baltimore on October 18th, and D.C. on October 19th).
At the end of October is the Mid-Atlantic Security Code Camp. If you are anywhere near Reston, Virginia during the last weekend in October, you should stop in. The line-up of talks should be available soon.
This concludes post #300. Past performance is no guarantee of future results.
Ted Neward has a great post analyzing new C# 3.0 features.
Ted refers to the language enhancements as mostly “syntactic sugar”. In other words - the syntax additions don’t change the expressiveness of C#, but merely add conveniences and shortcuts. We write less code while the C# compiler generates more IL behind the scenes.
Over the years I’ve been puzzled by the term ‘syntactic sugar’. People generally use the term in a derogatory sense, as in: “C++? Pffft. That’s just C with some syntactic sugar”.
Isn’t every language just syntactic sugar when compared to, say, CPU opcodes?
Rough and random thoughts while playing with the new Atlas bits.
Nifty master page tricks: the master page uses a ContentPlaceHolder inside the %lt;head%gt; tag, which makes it easy for content pages to override the contents of head. The master page does not define a %lt;form> tag, but leaves the content pages to define the tag (typically with action=”” since there are no postbacks involved).
Glitch: the setup puts a default.master and a default.aspx in the same directory, which can produce duplicate definitions for _default in the codegen directory. The errors appear in temporary files with scary names, and the errors come and go depending on how many files compile. It’s scenarios like this that make the system appear broken and one reason why people hate the project-less web project.
Cool: you can generate JavaScript proxies for a web service by browsing to the asmx file and appending /js (why not ?js to be consistent with ?wsdl?). Assuming you wire up a button’s onclick event, you can pull back and process results with relatively simple code. Lab 1 passes the contents of a textbox to a HelloWorld type service, which essentially echoes the input back with a timestamp.
function DoSearch()
{
var SrchElem = document.getElementById("SearchKey");
Samples.AspNet.HelloWorldService.HelloWorld(
SrchElem.value, OnRequestComplete
);
}
function OnRequestComplete(result)
{
var RsltElem = document.getElementById("Results");
RsltElem.innerHTML = result;
}
Lab 2 performs the same work as Lab 1, but with a declarative syntax. Instead of writing JavaScript you write a mess of declarative XML that only a machine can love. Excerpt:
<serviceMethod
id="helloService"
url="HelloWorldService.asmx"
methodName="HelloWorld">
<bindings>
<binding dataContext="SearchKey" dataPath="text"
property="parameters" propertyKey="query" />
</bindings>
<completed>
<invokeMethod target="resultsBinding" method="evaluateIn" />
</completed>
</serviceMethod>
Weep: Lab 2 didn’t work for me immediately and I had to stare at the XML and compare the above to what was in the sample. Not knowing what else to do I started stepping through the Atlas JavaScript. I was deep inside a JSON.serialize method when I realized it was building a payload like “query:foo”, where “foo” was the value I typed into the textbox and “query” was the name of the web service parameter – except I had named my parameter on the C# method differently.
I hope that none of the XML cruft will have to be hand written. I hope there will be some way to keep the XML and web method in sync, or decoupled. Lab 1 worked because the JavaScript proxy was custom generated from the code– I hope something along those lines will be available for the declarative service method bindings.
Lab 3 added auto-completion to the textbox control, which I found rather appealing in a scary way. When typing into the textbox the JavaScript will invoke a web service method and bring back a list of possible matches to display in a DHTML control.
Unfortunately, this lab started throwing a JavaScript exception, so once more I tried to step through the optimized-for-transport-no-whitespace JavaScript of the framework. I thought my head was going to explode. I gave up and posted on the asp.net forums, and found that changing:
<div id="completionList" />
to
<div id="completionList"></div>
made everything work.
Sigh.
Lab 4 implements the same auto-completion textbox as Lab 3, but with a server side Atlas control instead of client side gunk.
<atlas:TextBox
id="searchBox"
runat="server"
AutoCompletionServiceUrl="AutoCompleteService.asmx"
AutoCompletionServiceMethod="GetWordList"
/>
Sweet.
Lab 5 uses Atlas server-side controls to call a web method and populate a templated listview control. The word “bindings” appears a lot. Excerpt:
<atlas:Button runat="server" ID="fillButton" Text="Get URL List">
<click>
<actions>
<atlas:invokeMethodAction
target="dataSource1"
method="select" />
</actions>
</click>
</atlas:Button>
The declarative syntax feels passive and the terminology is vague, but I suppose that is the nature of the beast and something I have to get over.
This concludes my notes from the Atlas hands on exercises. I’m certain you have not enjoyed them half as much as I have enjoyed typing them in.
Concurrency is terribly difficult. Example: a primary cause of the massive North American blackout in 2003 was a software race condition. The application logged over three million production hours before the bug manifested itself.
Nevertheless, concurrency, here we come. Herb Sutter points out why with his article: “The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software”.
Mr. Sutter explains how future CPU improvements will no longer give applications a free performance boost - clock speed and execution optimizations are topping out. We need to increase the concurrency of our applications to take advantage of the next wave of CPU improvements (multiple cores).
Like Jeff Atwood, I don’t think concurrency is an area the typical application developer is ever going to deal with. Instead, the revolution will happen in the runtimes, the platforms, and the languages we use.
ASP.NET developers already use a runtime to write applications that process requests in parallel. Even a simple console mode program in the CLR has work happening concurrently. On the platform side, T-SQL developers have parallelism readily available with SQL Server’s Service Broker on the horizon.
While the platforms and runtimes are moving ahead, I’m not sure what is happening with languages. When Comega first appeared I thought the next version of C# would be taking a turn towards new concurrency abstractions, but I see no mention of these in the C# 3.0 specification.
As far as languages go, perhaps the LINQ / DLinq / XLinq features are enough to chew on and iron out first.
The beta version of the IE Developer Toolbar is now available. The toolbar allows you to inspect the DOM, view class names and IDs, clear the browser cache, validate the markup, and more.
Other than a minor annoyance (the installation required a reboot), the toolbar looks great and works well. If you’ve ever used FireFox’s web developer extension you’ll know just how invaluable this tool can be.
The IEDevToolbar.dll the setup package deploys doesn’t appear to use managed code, though. Bummer.
OdeToCode by K. Scott Allen
Subscribe
Twitter
Search
About
Learn C#