| Aaron Powell's profileAaron's spacePhotosBlogLists |  Tools  Help |
Aaron's space |
||||||
|
July 31 So long and thanks for all the fishI'm moving my blog off of Windows Live as I've finally got around to building myself a website. You can find me @ http://www.aaron-powell.com
July 25 Copying directories with MSBuildSo after a long time of avoiding it I have finally got into the MSBuild love (again colleague of mine, Alistair Deneys, is to thank/ blame
 ) but one thing that always frustrated the hell out of me is the copying of directories. MSBuild does not natively support it.Sure, there's the ItemGroup work around which can achieve it, it's good, but has problems with the relative pathing of the files, also it isn't overly flexible when it comes multiple file types within a folder or limiting folder recursion depth.
And I always forget the syntax, it is such a pain to have to remember all the time (especially how to specify where to output to!), here's an example of using it, I'm copying custom macros for Umbraco from my Web Application into my Umbraco folder:
<CreateItem Include="UserControls\**\*.ascx">
<Output ItemName="UserControls" TaskParameter="Include" /> </CreateItem> <Copy SourceFiles="@(UserControls)" DestinationFiles="@(UserControls->'$(UmbracoRoot)\%(relativedir)%(Filename)%(Extension)')" SkipUnchangedFiles="true" /> And then if I wanted to include the XSLT folder, CSS, etc, I need to write one for each I want. And to get back to my a point earlier you're in trouble if the files you want to copy aren't within the current projects structure, or you only want a sub-structure of a folder in your project (say my UserControl folder was actually in <Project>\Umbraco\UserControls).
I'm by no means a MSBuild expert, I'm sure there's some kind crazy work around but from my investigations it was becoming a royal pain in the arse!
So to solve the problem I just wrote my own MSBuild task to do it, so introducing Aaron Powell's MSBuild Tasks! This zip includes the MSI installer or standard setup EXE. I must warn you that at the time or writing this the task is still quite definately beta (this is the 0.1.0 release), it'll run, operate as required but definately does not have the best error checking or logging yet (or documentation... yeah really should have some of that one day!
 ).What's it do? Well it taks a source folder and a destination folder (at the very least) and copies the contents along with sub-structures. The task has properties to define the extensions of the files to copy, how many levels deep to go and what to do about unchanged files.
To use the task add the Import statement and then an instance of the task:
< Import Project="$(MSBuildExtensionsPath)\AaronPowellMSBuildTasks\AaronPowell.MSBuild.Tasks.Targets" /><!-- Snip -->
<
So now the task when executed will copy all files with the PNG or DOC extension within the specified source for a recursion depth of two. The defaults for the non-mandatory properties are:
Known limitations/ issues There are several known limitations, which is why I stress this to be beta at the time of writing:
Anyway I hope to bring out 1.0.0 soon which should solve/ address the above limitations/ issues plus any others which I come across during testing. July 14 Is LINQ to SQL a DAL?So the other day a colleague of mine, Alistair Deneys, the other day said to me "LINQ to SQL is not a DAL, it's just a replacement of DataSets" and that got me thinking about what LINQ to SQL really is. So is LINQ to SQL a DAL? Well this blog I'm going to have a look at that question.
What is a DAL?
Before we can draw any conclusions we need to first look at what is a DAL. Primarily a DAL is to handle the interfacing between your code and your databases. But keep in mind that there's a difference between a DAL and a code generator (which most DAL's include anyway).
So a DAL handles how we translate our normal programming language into data queries, and most have a code generator to mean we write less code. So what does LINQ to SQL provide us with:
So LINQ to SQL provides us with many features which are found in many other DAL's, be that LLBL or the WDG Class Library. CRUD Agrueably the primary point of a DAL is CRUD, and this is something build into LINQ to SQL, I wont go over it hear as there are hundreds of posts which cover how to do standard CRUD operations from LINQ to SQL. Extensibility A DAL which provides code generation needs to be extensible, it is no good being given a set of classes and that's all you'll ever have... well that's pretty much pointless now isn't it. The same goes for LINQ to SQL. All generated classes in LINQ to SQL are partial classes (as they should be) which means you can quite easily write your own methods into the class at both static and instance level (depending on what level of access you need to the data). And using IQueryable<T> you can provide access to the delayed execution feature of LINQ to SQL. So is it a DAL? The short answer to this question is "yes", with a long answer of "it can be". For a lot of needs LINQ to SQL will provide all that you need to do DAL operations, you get generated code to perform CRUD operations, you can write methods in your chosen format and the classes can be serializable. But it's not for everyone. The biggest limitation of LINQ to SQL is the lack of templates, basically when you generate code you'll always get the same code and this may not be ideal if you have specific requirements for a particular project, in that case a templated code generator like LLBL, or Code Smith are a better option, provided you a) you can find your templates or b) you have time to write your templates June 16 DataContractJsonSerializer vs JavaScriptSerializerWhen ASP.NET AJAX shipped last year it came with a class do help with converting objects into JavaScript Object Notation (JSON), in the form of the JavaScriptSerializer. This is a great little class which will create a JSON string with no real troubles from any existing class, or convert a JSON string into a .NET object. But with .NET 3.5 this class was flagged as obsolete with the replacement being in the form of the DataContractJsonSerializer (yeah, that's a mouthful!). As ScottGu pointed out in a blog post last year the obsoleting of the JavaScriptSerializer isn't logical, especially since it only came in from the ASP.NET AJAX 1.0 release. Well what's the difference between the two? The DataContractJsonSerializer The primary purpose of the DataContractJsonSerializer is to be used with WCF, since one serialization is a big focus of WCF. Also, it is also better equipped to handle complex classes which have only certain properties available for serialization. This class is more strongly typed, has more knowledge about the type(s) it's handling and better error handling for badly-formed JSON. It also uses Streams to do the reading/ writing, making it a lot more suited for not just web, but for writing to files, etc. The JavaScriptSerializer This class on the other hand is much better equipped for quick serialization, it's a more cowboy approach. There's less error checking and less control over what properties which are serialized. So what to use? Like every time there's multiple options available within the .NET framework there's no clear winner. Obviously the DataContractJsonSerializer is the primary choice, due to the obsolete nature of the JavaScriptSerializer. But as ScottGu stated it'll be around for several .NET versions to come so using it wont cause your application to break on the next .NET drop. But not so quick, there's an interesting note on the way the serialization occurs, well more importantly, how the Reflection is employed to create the serialized string (or stream). Lets say we had a class like this: [Serializable] public class MyClass { public string Property1 { get; set; }} The JavaScriptSerializer is a very brutal, but efficient manner of conversion. Using the above close you'll receive a JSON string like this: { "Property1" : "value1", "Propert2" : "value2", "Property3" : "value3" } Nice, simple, clean JSON. This is very usable in terms of JavaScript, and it's returned nicely as a string from the Serialize method on the class. The DataContractJsonSerializer on the other hand is a bit tricker. Because it employs streams you need to decode the stream to get it into a string (there's an example of it's usage on Rick Strahl's blog). In addition the string you end up with is a bit different, the above class will result in this: { "<Property1>k__BackingField" : "value1", "<Property2>k__BackingField" : "value2", "<Property3>k__BackingField" : "value3" } Hmm that doesn't look right! Yep, that's not going to convert very well into a JavaScript object. Why did that happen when the JavaScriptSerializer did such a nice job? Well we have to look at the code that is actually generated for our class. Because we've used the short-hand notation of declaring properties (which are available within the C# 3.0/ VB 9.0 compilers) we haven't specified the variables which the property will store its data within, and this is what the DataContractJsonSerializer looks for. If you were to have specified the variables to use with the property getter/ setter methods then you wouldn't have the above problem. So keep these differences in mind when you're looking to do some JSON serialization :) May 24 Validating ASP.NET validators yourselfI'm sure at some point you've wanted to call a validation check on an ASP.NET page before the IButtonControl is clicked.
Well if you haven't maybe one day you will and hopefully this will decrease the time you spend on digging to get the solution.
The validator controls do have a JavaScript component to them (which I'm sure we're all aware of) which does the client side validation (to go into the ValidationSummary control if you implement one). So here's what you need to do to run it yourself.
First, there is an array containing all validations:
Page_Validators
This contains all validation controls on a page, from all validation groups so we need to itterate through them for only your required ones:
for(var i = 0; i < Page_Validators.length; i++){
var val = Page_Validators[i];
}
So now we have our validator, we should validate it. Because we're doing everything through the .NET framework we can use some useful features of, particularly with the pre-written ASP.NET validator controls and the ability to do the client-side validation, such as this function:
ValidatorValidate(val, validationGroup);
Because this is JavaScript all we need is the first argument but thought it'd be worth while including the ValidationGroup property.
Once ValidatorValidate is completed we can now check the isValid property of the Page_Validator for its validation state.
So lets put this all together:
function ValidatePage(){
var isValid = true;
for(var i = 0; i < Page_Validators.length; i++){
var val = Page_Validators[i];
ValidatorValidate(val, "group");
if(!val.isValid) isValid = false;
}
return isValid;
} So there you go, you can validate a page nice and easy. You can always go futher with this and validate some specific validator, or the one(s) for a form field, etc.
This can be used with the ASP.NET AJAX framework during the request live cycle, since the client-side validation isn't properly supported between the ASP.NET validator controls & AJAX framework.
So you can have something like this:
function initializeRequest(sender, initializeRequestEventArgs){
var prm = Sys.WebForms.PageRequestManager.getInstance();
var isPageValid = ValidatePage();
if(!isPageValid && prm.get_isInAsyncPostBack()){
initializeRequestEventArgs.set_cancel(true);
//notify user
}
}
And there you go, validation solved for the ASP.NET AJAX framework and standard validators. |
|||||
|
|
