Tuesday, December 11, 2007
UPDATE (12/17/2007): My blog has moved. This post is now located at:
http://jason.whitehorn.ws/2007/12/11/ASPNET+MVC+With+AspNETserve.aspx
I am pleased to announce that
aspNETserve works with the latest CTP of
MVC for ASP.NET.
aspNETserve has held up well against the MVC samples I have thrown its way, and has actually not required any code changes in aspNETserve.
Let me know if you run into any problems with this.
Monday, December 10, 2007
UPDATE (12/17/2007): My blog has moved. This post is now located at:
http://jason.whitehorn.ws/2007/12/10/Using+ASPNET+MVC+From+Visual+Web+Developer+Express+2008.aspx
Today marked the released of the first preview of
MVC for ASP.NET. While it works just fine from the free
Visual Web Developer Express 2008, this release is missing a project template to help you get up an running quickly.
So, I have thrown together a project template to allow you get get starting using MVC from VWD Express. Unlike VWD Express' big brother, VWD Express seems unable to create Web Application, only Web Sites. So this template has a slightly modified layout from the one available from Visual Studio.
Since Web Site projects can only arbitrarily host classes in the App_Code directory, I have placed the Models and Controllers there. The Views are located in an appropriately named directory off of the site root.
There are two versions of this template, one for C# and one for VB.NET.
ASP.NET MVC Web Site For C#
ASP.NET MVC Web Site For VB.NET
Download the template of your choice to the Visual Studio 2008\Templates\ProjectTemplates\Visual Web Developer directory located in your "My Documents" directory. After doing so, simply start VWD Express and you will notice a new template available when you go to create a new web site.
This was just something that I threw together really quickly, and is not intended to be a demonstration of MVC. It is simply a starting point for getting started quickly with MVC. If you should encounter any difficulties with this, please let me know.
Sunday, December 09, 2007
UPDATE (12/17/2007): My blog has moved. This post is now located at:
http://jason.whitehorn.ws/2007/12/09/aspNETserve+Version+12+Finally+Released.aspx
Just today I was able to release
aspNETserve version 1.2!
After the birth of my son I took a few months off, so this project sat dormant for awhile. Now that he has been sleeping regularly (and I have too
), I have been able to contribute to my open source project again.
If you haven't checked out
aspNETserve, you should really look into it. It is by no means a replacement for IIS, not yet anyways. But, it still proves to be very helpful. One of the new features in version 1.2 that I am excited about is the "Host in aspNETserve" context menu. From just about anywhere in Windows you can now right click on a directory and start hosting your web application.
I cannot think of how many times I have downloaded sample web applications off the net, and had wished I had this feature earlier. Now you can take that website for a test spin without having to configure IIS.
Friday, December 07, 2007
UPDATE (12/17/2007): My blog has moved. This post is now located at:
http://jason.whitehorn.ws/2007/12/07/NET+Wiki+Weekend+Update+1272007.aspx
Its been a great week on the
.NET Wiki. There have been a few newly registered users, and several pages added.
The updated pages include:
Value Type
Access Modifier
LINQ
Silverlight
Additionally I managed to updated our version of
ScrewTurn Wiki to the latest version (2.0.21, up from 2.0.20).
Things are really moving along nicely.
UPDATE (12/17/2007): My blog has moved. This post is now located at:
http://jason.whitehorn.ws/2007/12/07/The+Design+Of+Code.aspx
Jonathan Starr in a
recent post, asked his readers:
"As we software engineers refactor someone else's code [...] at what point is the new application essentially not the same as the legacy application that you improved?"
Software rarely occurs in isolation, especially enterprise software. Often years of business rules, legacy systems, and even unjustified rational guide and shape the applications we work on.
When you are involved in a massive re-engineering of an existing application, you typically work you way piece-wise through the code. It is in this fashion that you systematically rework entire subsystems of the application. During this process we are hardly aware that, despite our best intentions, we are not truly guiding the design of the application. The legacy design is guiding its own redesign.
We often have to shape our ideas to fit into the legacy mold the application presents. This, coupled with the same business needs and environment that shaped the application originally, is precisely why most applications never truly change. The source code may look different, however the differences is purely cosmetic. Much the same as how an adult is still the same person as they were as a child. The adult has a few new behaviors, some they don't perform any more. The adult even looks, walks, and sounds different. But the adult is still the same person they were as a child.
An application can only truly be reborn, when it is clean room re-engineered, as anything short of this would re-introduce the "
spirit" of its predecessor.
UPDATE (12/17/2007): My blog has moved. This post is now located at:
http://jason.whitehorn.ws/2007/12/07/Making+Visual+Studio+Load+Faster.aspx
Tired of Visual Studio being sluggish?
Well, I can't help you there. But I can tell you how to make it start up faster. You simply need to disable the startup screen.
Really, you didn't use that screen anyway ;-)
To disable it, goto to the
Tools menu, and select the
Options option.
From the
Options menu, navigate to the
Environment tree option, then the
Startup option.
From here you can select the
Show empty environment value for the "At Startup" drop down.
There you go, that will disable that sluggish startup screen!
Sunday, December 02, 2007
UPDATE (12/17/2007): My blog has moved. This post is now located at:
http://jason.whitehorn.ws/2007/12/02/Blog+Badges.aspx
Like badges? I know I do, so here you go:
Source code:
<a href="http://www.marshalbyrefobject.net/wiki/MainPage.ashx" border="0">
<img src="http://www.marshalbyrefobject.net/media/dotnet-wiki_80x15.png" alt="dotNet wiki" />
</a>
Spread the word for the .NET wiki by adding this bade to your blog!
Wednesday, November 28, 2007
UPDATE (12/17/2007): My blog has moved. This post is now located at:
http://jason.whitehorn.ws/2007/11/28/See+You+In+Tulsa.aspx
A Visual Studio 2008 InstallFest will be held this Monday (12/3/2007) in Tulsa Oklahoma. The event is sponsored in part by
TulsaDevelopers.NET.
I will be at the event, so if you see me let me know.
Tuesday, November 27, 2007
UPDATE (12/17/2007): My blog has moved. This post is now located at:
http://jason.whitehorn.ws/2007/11/27/NET+Wiki.aspx
I have just launched a Wiki devoted to all things .NET. You can check it out at
MarshalByRefObject.net/Wiki/.
The site is new, so there is still lots of room for improvement. So if you see anything you'd like see improved, just let me know.
Friday, November 09, 2007
UPDATE (12/17/2007): My blog has moved. This post is now located at:
http://jason.whitehorn.ws/2007/11/09/The+Wonders+Of+InternalsVisibleTo.aspx
I do not know how I missed this, but just today I found out that you can expose an assembly's internal methods/properties/classes to a "friend" assembly. Normally internals are only accessible to members of the same assembly, and are often used to hide "plumbing" methods and utilities classes.
For many reasons you often want to separate your code into multiple assemblies, perhaps one for each application layer or some other logical boundary. A problem arises when two or more assemblies need access to each others internals. Prior to .NET 2.0 you had two choices, either expose these plumbing methods as public, or lump as much of your code into one assembly as was needed to keep the plumbing internal.
In comes .NET 2.0's
InternalsVisibleTo attribute. This attribute is applied on the assembly level, and allows the assembly to give internal access to specific assemblies.
For example:
Say you have two assemblies,
MyExample.DomainObjects &
MyExample.ServiceLayer. In the DomainObjects assembly you have the following abstract class:
namespace MyExample.DomainObjects{
public abstract class DomainObject{
//.... other things....
public virtual DateTime LastModifiedDate{
get { ... }
internal set { ... }
}
}
}
In the above example you would like to have your service layer in a separate assembly from you domain objects. You would also like to have a LastModifiedDate property for each of your domain objects, but you would prefer if it was only settable by your service layer.
This is were the InternalsVisibleTo comes in handy. In the DomainObjects assembly you can added the InternalsVisbleTo attribute to give only the ServiceLayer assembly access to any and all internal items. For unsigned assemblies the attribute would look like:
[assembly: InternalsVisibleTo("MyExample.ServiceLayer")]
This is straight forward when the target assembly is unsigned, but gets a little more difficult when the target assembly is signed. For signed assemblies you will need the assembly's public key. This is not to be confused with the assembly's public key
token, which is often what you see. To acquire the public key of a signed assembly you will need the "sn.exe" tool that ships with Visual Studio.
From the "Visual Studio Command Prompt":
sn -Tp c:\Users\jason\projects\MyExample\MyExample.ServiceLayer.dll
NOTE: the "sn" command takes a big "T" and a little "p" for the switch, and you will need to replace my example path with your own ;-)
Whats pops out of this handy little program is both the public key, and the public key token. The one we needs is the longer one, the public key. With this in hand we can now add the appropriate attribute to our DomainObjects assembly.
[assembly: InternalsVisibleTo("MyExample.ServiceLayer, PublicKey=0024000004809{key shortened for readability}30a09825a6999")]
NOTE: The public key is much longer than what is shown above. The above sample is intentionally incorrect for legibility. For this to work you will need to copy and paste the public key in its entirety.
With the public key added to the assembly name on the attribute our example ServiceLayer assembly can access the internals of the DomainObjects assembly.
Additionally, since the InternalsVisibleTo attribute references the friend assembly by its string name, no real dependency is created from our DomainObjects assembly to our ServiceLayer assembly. The DomainObjects assembly will continue to work with or without the ServiceLayer assembly present.
Wednesday, October 31, 2007
UPDATE (12/17/2007): My blog has moved. This post is now located at:
http://jason.whitehorn.ws/2007/10/31/Enable+MS+DTC+On+Windows+Vista.aspx
To enable MS DTC on Windows Vista simply follow the instructions from:
http://technet2.microsoft.com/windowsserver2008/en/library/1f6d0a27-533b-4516-8656-b492f1649e9f1033.mspx?mfr=true
MS DTC appears to be required to use System.Transactions against SQL Server, and is disabled by default.
Tuesday, July 03, 2007
UPDATE (12/17/2007): My blog has moved. This post is now located at:
http://jason.whitehorn.ws/2007/07/03/A+Possible+Solution+To+The+NET+35Visual+Studio+2005+Feud.aspx
In
my previous post I discussed a problem of developing ASP.NET 2.0 applications in Visual Studio 2005, while having the .NET 3.5 framework installed. In summation, the issue was because Visual Studio 2005 was linking against a library that shipped with .NET 3.5 instead of the explicitly referenced version from the web.config.
The comments of one reader of
my previous post mentioned using
binding redirection to resolve the issue. In short, it looks like they were correct. As best as I can tell, binding redirection does in fact fix this issue.
Binding redirection is the ability to take a pre-compiled application and tell the loader to link against a different version of a library than the application was originally built with. In our case, we would need to add the following configuration to our web.config.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Extensions" publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="2.0.0.0" newVersion="1.0.61025.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
The above configuration tells .NET to use System.Web.Extensions version 1.0.61025 instead of version 2.0.0.0. While the above does pose to be a solution to the problem, it is concerning that this would be needed at all.
Saturday, June 30, 2007
UPDATE (12/17/2007): My blog has moved. This post is now located at:
http://jason.whitehorn.ws/2007/06/30/NHibernate+Criteria+Queries.aspx
NHibernate's support for criteria queries provides an extremely powerful query feature into an easy to use package. NHibernate has a rather complete manual that covers criteria queries, which you can checkout here.
The NHibernate documentation has a ton of information packed within it, and can be a little overwhelming for those who are new to NHibernate. So, as an argumentation to the documentation for criteria searching, I will provide a really basic overview of how things work.
The NHibernate session exposes a method called "CreateCriteria", which accepts a Type and returns an ICriteria. This is the starting point for any criteria query. The Type you pass the method, is the same Type that you are querying for. For example, if you have a business object call "Customer" that we want to search for using criteria, you would:
ICriteria crit = session.CreateCriteria(typeof(Customer));
Now that you have created an ICriteria object to represent your search, you need to start specifying various criteria for the object NHibernate will fetch. This is were the "Add" method comes in handy.
The Add method accepts any ICriterion object, but to help you along NHibernate provides the "Expression" object which has many static methods to help you form your criteria. Continuing with our running example, if you want to select customers who are older than 21 years of age you would:
crit.Add(Expression.Gt("Age", 21));
The above code tell NHibernate that the "Age" property of our Customer object needs to be greater than the value 21. In the above manor, you can use the Add method and the Expression object to specify exactly which objects you want to retrieve.
To actually fetch our objects from the database, you execute the "List" method on the ICriteria object.
IList results = crit.List();
There are many more capabilities of criteria queries in NHibernate that I have not even touched upon, which you can read more about in the official NHibernate documentation.
Tuesday, June 26, 2007
UPDATE (12/17/2007): My blog has moved. This post is now located at:
http://jason.whitehorn.ws/2007/06/26/Parsing+RSS+From+C.aspx
I set out to write a RSS parser in C#. I know that several existing libraries are available for .NET that parse RSS streams, but out of curiosity I wanted to give it a go anyway.
Before I get started, for those interested in RSS libraries for .NET checkout
RSS.NET or
RSSConnect, to just name two.
As .NET developers we have some really powerful tools available to us that are built directly into the .NET framework. Take, for example, Serialization. In .NET we can turn an object into an XML resource using the
XmlSerializer class, provided that the class is
Serializable. In fact, the XmlSerializer object will even attempt to populate an object from an XML resource.
Visual Studio ships with a tool called XSD which can turn an XML Schema Definition into a C# class. Knowing that RSS is expressed as an XML resource, I set out to find an XSD for RSS. After some searching I found
this site, which contains an XSD for RSS that the site's author wrote. For posterity I have placed a mirror of that file on my own site, which you can find
here.
Before continuing on, I need to pause and look ahead. The XSD that I found did not work out of the box, and I had to make a small modification to get it to work. I removed a reference to the RSS schema namespace from the XSD. The modified XSD can be downloaded from
here
Now, armed with an XSD, we can have the XSD program make some classes for us. From a command prompt (preferable the "Visual Studio Command Prompt" command prompt) type:
xsd RSS20.xsd /classes
Provided that RSS20.xsd is the name of the RSS XSD, and that you are currently in the same directory as RSS20.xsd, the XSD program should output a single file called RSS20.cs. The C# source file that XSD produced contains a class definition for each RSS entity, most notable the root node called "rss".
With classes that represent RSS, we can now use the XmlSerializer object to easily populate an object with RSS data. For example:
string rssXml = "... your rss data here ...";
XmlSerializer helper = new XmlSerializer(typeof(rss));
rss obj = (rss)helper.Deserialize(new StringReader(rssXml));
The above code snippet, will create an rss instance called "obj" from raw RSS data. But, you don't want to have to do this everytime you want to parse RSS. Instead, it would be helpful if that logic was encapsulated by the rss object. Fortunately, the classes produced by the XSD program are all partial classes. So, in a separate .cs file, we can re-declare the rss class and expand upon its functionality.
//declare another portion of the "rss" object.
public partial class rss{
//add more methods to "rss" here
}
Ideally it would be nice to have both a method to turn an RSS stream into an rss object, and a method to output RSS from an rss object. For example:
public partial class rss{
public static rss Parse(string rssXml) {
//turn an RSS string, into an rss object.
}
public override string ToString() {
//turn the rss object into a RSS string.
}
}
The above two methods can both be implemented using the XmlSerializer object, as it provides methods to serialize and deserialize and object. I ended up with the following implementation.
public partial class rss{
public static rss Parse(string rssXml) {
return (rss)Serializer.Deserialize(new StringReader(rssXml));
}
public override string ToString() {
string result;
using (StringWriter sw = new StringWriter()) {
Serializer.Serialize(sw, this);
result = sw.ToString();
}
return result;
}
private static XmlSerializer Serializer {
get {
if (_serializer == null)
_serializer = new XmlSerializer(typeof(rss));
return _serializer;
}
}
private static XmlSerializer _serializer;
}
The above implementation, combined with the output from the XSD program, is a functional RSS parser. The above code can be used to process blog output, or price feeds from your favorite online retailer.
As an added bonus, I wrote two additional methods for rss from those outlined above.
//optionally, you can add these two methods to "rss".
public static rss CreateFrom(Uri location) {
rss result;
using (WebClient helper = new WebClient()) {
string rawRss = helper.DownloadString(location);
result = Parse(rawRss);
}
return result;
}
public static rss CreateFrom(string location) {
return CreateFrom(new Uri(location));
}
For those interested, a compiled version of this code can be download from
here.