June 23, 2011 06:03 by
ScottVisual Studio has a cool user interface for publishing a website using the Publish Web Site dialog, accessible by selecting Build, Publish Web Site. You can use this dialog to pre-compile your website and avoid having to deploy source code.
Visual Web Developer Express doesn't offer this dialog, but because the Publish Web Site dialog is just a front-end for aspnet_compiler.exe, you can use aspnet_compiler.exe from a command prompt to accomplish the same thing if you are a VWD user. While using aspnet_compiler.exe from a command prompt gives you the same functionality, using a menu option is a lot more user-friendly and avoids possibly typos that can be frustrating.
In this post, I'm going to show you how you can add some menu options to VWD that will automate the user of aspnet_compiler. It won't give you the same flexibility and convenience you get with the full-blown Visual Studio, but it will come darn close.
Note: While I will show these steps in Visual Web Developer 2005 Express Edition, you can use the same steps for Visual Web Developer 2008 Express Edition.
To add the new menu item, I'll use the External Tools option on the Tools menu in VWD. (This menu option is also available in Visual Studio.) Using the External Tools dialog, you can add menu items that will execute external applications, and you can also control command line arguments that are passed to your external application and more.
Note: I also explain how to do this in my book, The Expression Web Developer's Guide to ASP.NET 3.5.
We'll create two menu items; one for pre-compiling an updatable application and another for a non-updatable application.
1. Launch Visual Web Developer Express.
2. Select Tools, External Tools to display the External Tools dialog.
3. In the Title box, enter Pre-&Compile (non-updatable).
4. Click the browse button next to the Command box and browse to aspnet_compiler.exe located in c:\Windows\Microsoft.NET\Framework\v2.0.50727.
5. Click Open to add the command line for aspnet_compiler.exe.
Now that you've got the correct command line for the aspnet_compiler.exe, it's time to add the arguments that will correctly pre-compile your application. This is where you'll see the true power of the External Tools dialog.
1. Type -p " in the Arguments box. (That's an opening double-quote after the p.)
2. Click the right-facing arrow next to the Arguments box and select Project Directory.
3. Add a trailing double-quote to the Arguments box.
4. Press the spacebar to add a space at the end of the existing arguments.
5. Type -v / " after the space you just entered.
6. Click the right-facing arrow next to the Arguments box and select Project Directory.
7. Type \..\CompiledApp" after the existing arguments.
At this point, the Arguments box should contain the following:
-p "$(ProjectDir)" -v / "$(ProjectDir)\..\CompiledApp"
Now check the Close on Exit checkbox and click OK to add the new command to your Tools menu.
You can create another menu item that will compile the application and allow it to be updated by creating another entry using Pre-Co&mpile (updatable) as the Title and by appending -u to the arguments.
After you complete these steps, your pre-compiled application will be saved at the same level as your application's folder. For example, if your website exists in the c:\MyWebsites\WebApplication1, the pre-compiled application will be saved to c:\MyWebsites\CompiledApp. If that folder structure doesn't suit you, you can alter the steps above for your own purposes.
June 22, 2011 05:55 by
ScottRemote validation has finally landed in RC1 of ASP.NET MVC 3. It’s a weird area as more often than not people tend to over complicate something that is really pretty simple. Thankfully the MVC implementation is fairly straightforward by simply providing wiring allowing the jQuery Validation plugin to work it's magic. Basically there is a new Remote attribute that can be used like so.
public class Credentials
{
[Remote("Username", "Validation")]
public string Username { get; set; }
public string Password { get; set; }
}
As you can see we have attributed the Username field with a Remote attribute. The 2 parameters tell us what Action and Controller we should call to perform the validation. This does make me feel slightly uneasy as it kind of feels like you are coupling the controller to the model which doesn't sit right by me. currently sitting on the fence I'll see how it works in real life. Anyway I implemented it like so,
public class ValidationController : Controller
{ public ActionResult Username(string UserName)
{
return Json(Repository.UserExists(Username), JsonRequestBehavior.AllowGet);
}
}
And thats you - provided you have the necessary client side libraries included of course (jQuery, jQuery Validate etc). and have Client Side Validation turned on (now by default in MVC3).
Configuration
The Remote attribute offers a few nice little configuration options to make things easier. The typical ones are there such as ErrorMessage, ErrorResource etc. but there are a few specific ones as well.
Fields
There may be a case where ding the name and the value of a single form field isn’t enough to perform validation. Perhaps validation is affected by some other field/value in the form. The Remote attribute accepts a comma separated list of other fields that need to be sent up with the request using the Fields parameter
This basic example will send up the value of the EmailService input field along with the value of Username. Clean and simple.
[Remote("Username", "Validation", Fields = "EmailService")]
HttpMethod
HttpMethod simply allows us to change how the ajax request is sent e.g. via POST or GET or anything else that makes sense. So to send a remote request via POST
[Remote("Username", "Validation", HttpMethod = "POST")]
A Minor Difference
You might notice if you read the release notes for RC1 that my implementation of the controller is slightly different. The reason being that the example in the release notes is broken :-). The example looks like this
public class UsersController {
public bool UserNameAvailable(string username) {
return !MyRepository.UserNameExists(username);
}
}
However the Validate plugin expects a JSON response which is fine on the surface but returning a boolean response to the client side results in a response body of False (notice the captial F) which in turn causes a parse error when the plugin performs JSON.parse. My suggested solution is actually more inline with how most people would typically write an Ajax capable controller action anyway (though I am not happy with the JsonRequestBehaviour usage) but there are other ways but they aren’t pretty….
public class ValidationController : Controller
{
public string Username(string username)
{
return (!Repository.UserExists(Username)).ToString().ToLower();
}
}
See? Ugly and plain WRONG (but it will work).
Nice to see this feature finally landing as it can be useful in certain situations.
June 9, 2011 05:22 by
Scott