Git E-VAN
Just a reminder that tonight I’ll be doing an E-VAN on Git tonight at 7pm GMT.
It’s going to be a pretty basic talk on what Git is (and indirectly what DVCS is), and a demo on how to use most of the features you’ll need daily. There might be some advanced talk at the end, depending on how well I time things.
If you’ve already used Git (successfully), then this talk won’t really be for you; unless you just want to listen to me ramble for an hour and an half.
Looking forward to “seeing” you there. Now, I best finish reading that “Getting started with Git” book I’ve had lying around for months.
Cascading dropdown column in a SharePoint 2007 List
Say hello to Uber Prof
I got several requests for this, so I am making Uber Prof itself available for purchasing.
What is Uber Prof?
It is a short hand way of saying: All the OR/M profilers that we make.
An Uber Prof license gives you the ability to use:
And it will automatically give you the ability to use any additional profilers that we will create. And yes, there is an upgrade path if you already purchased a single profiler license and would like to upgrade to Uber Prof.
Back to Basics – Using MasterType Directive
This post is
a result of
a question that
I got from one
of the developers
that I work with.
The question was
how to use master page properties from an ASP.NET page.
The first thing that you want to do is to expose the properties
as public in the master page. For example this is code behind
of a simple master page that exposes the IsPageEnabled property:
public partial class Site1 : MasterPage
{
#region Properties
public bool IsPageEnabled { get; set; }
#endregion
#region Page events
protected void Page_Load(object sender, EventArgs e)
{
}
#endregion
}The MasterType Directive
When we want to use the property in a page which reference the
previous master page we need to put the inside of it the MasterType
directive:
<%@ MasterType VirtualPath="~/Site1.Master" %>
This directive declare that the master page of a page is strongly type.
By that simple directive we gain access to the master exposed public
properties and methods through the Master property of the page.
For example this is how in the page I’ll call the IsPageEnabled property of
the master page:
public partial class WebForm5 : Page
{
#region Page Events
protected void Page_Load(object sender, EventArgs e)
{
Master.IsPageEnabled = true;
}
#endregion
}
The markup of the page I use:
<%@ Page Title="" Language="C#" MasterPageFile="~/Site1.Master" AutoEventWireup="true"
CodeBehind="WebForm5.aspx.cs" Inherits="TestModalDialog.WebForm5" %>
<%@ MasterType VirtualPath="~/Site1.Master" %>
<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" runat="server">
</asp:Content>Summary
Lets sum up, when we use master pages we can expose properties
and methods for the pages. We use the MasterType directive in the
page in order to create a strong type master page inside of it. By
doing that we can pass data from the page to its master.
Very easy and very useful.
Built-in Charting Controls (VS 2010 and .NET 4 Series)
[In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu]
This is the fifteenth in a series of blog posts I’m doing on the upcoming VS 2010 and .NET 4 release. Today’s post covers a nice addition to ASP.NET and Windows Forms with .NET 4 - built-in charting control support.
ASP.NET and Windows Forms Charting ControlsA little over 14 months ago I blogged about how Microsoft was making available a free download of charting controls for both ASP.NET 3.5 and Windows Forms 3.5.
You can download and use these runtime controls for free within your web and client applications today. You can also download VS 2008 tooling support for them. They provide a rich set of charting capabilities that is easy to use. To get a sense of what all you can do with them, I recommend downloading the ASP.NET and Windows Forms sample projects which provide more than 200 samples within them. Below is a screen-shot of some pie and doughnut chart samples from the ASP.NET sample application:
Charting Controls Now Built-into .NET 4With .NET 3.5 you had to separately download the chart controls and add them into your application. With .NET 4 these controls are now built-into ASP.NET 4 and Windows Forms 4 – which means you can immediately take advantage of them out of the box (no separate download or registration required).
Within ASP.NET 4 applications you’ll find that there is now a new built-in <asp:chart> control within the “Data” tab of the Toolbox:
You can use this control without having to register or wire-up any configuration file entries. All of the charting control configuration is now pre-registered with ASP.NET 4 (meaning nothing has to be added to an application’s web.config file for them to work). This enables you to maintain very clean and minimal Web.config files.
Learning more about the <asp:chart> controlScott Mitchell has written a great series of articles on the www.4guysfromrolla.com site on how to take advantage of the <asp:chart> control:
- Getting Started - walks through getting started using the Chart Controls, from version requirements to downloading and installing the Chart Controls, to displaying a simple chart in an ASP.NET page.
- Plotting Chart Data - examines the multitude of ways by which data can be plotted on a chart, from databinding to manually adding the points one at a time.
- Rendering the Chart - the Chart Controls offer a variety of ways to render the chart data into an image. This article explores these options.
- Sorting and Filtering Chart Data - this article shows how to programmatically sort and filter the chart's data prior to display.
- Programmatically Generating Chart Images - learn how to programmatically create and alter the chart image file.
- Creating Drill Down Reports - see how to build drill down reports using the Chart control.
- Adding Statistical Formulas - learn how to add statistical formulas, such as mean, median, variance, and forecasts, to your charts.
- Enhancing Charts With Ajax - improve the user experience for dynamic and interactive charts using Ajax.
His articles are written using .NET 3.5 and the separate ASP.NET charting controls download – but all of the concepts and syntax work out of the box exactly the same with ASP.NET 4.
Michael Ceranski has also written a blog post demonstrating how to use the ASP.NET Chart control within an ASP.NET MVC application. I’m hoping someone will create some nice ASP.NET MVC Html.Chart() helper methods soon that will make this even easier to do in the future.
Hope this helps,
Scott
Headed To Austin and Speaking at the .NET User’s Group
The stars at night, are big and bright – clap clap clap clap – deep in the heart of Texas!
Hold onto your ten gallon hats, I’m visiting Texas for the first time! I’m very excited to visit the second largest state in the union. ;)
The purpose of my trip is to meet with some developers at Dell doing interesting things and to give a talk there as well.
But since I’ve heard such good things about the vibrant tech community in Austin, I am trying to make the most of my short trip. On Thursday, February 25, I’ll be speaking at Austin .NET User Group meeting at 5:30 PM CST (Location TBD, I’ll post it here when I find out or follow @ehexter on Twitter). So be sure to come by and say hello.
I’m also going to visit my good friends at Headspring as well as Dovetail Software to jabber about technology and see what cool things they’re doing with ASP.NET and ASP.NET MVC.
And of course, a trip to Austin wouldn’t be complete without a night out on the town with Bellware. I expect chaos. ;)
Tags: austin, texas, .net user groupUnderstanding Web Forms and Web services in ASP.NET
LineCap, DashCap, and DashStyle in GDI+
The Switch Class in C#
Michael Cummings on XNA Development Part 2
Cloning Windows Solitaire Game in Silverlight 3 - Part 2
Pex, Unit Test but Better, Parameterized Unit Testing

Finally I had a chance to play with the Pex (Program EXploration) , I heard it on lang.net for the very first time and I was quite impressed, but it took a while to explore it.
I downloaded the latest commercial evaluation package 0.22.50128.1 from Pex web site.
It is about 12 MB, it comes with different installation options with the support of VS 2008 and 2010. It installed without any problems on my VS2010 beta 2.
Here is what you get from the installation :
- Pex command line (Visual Studio not required)
- Pex Visual Studio Add-in, for Visual Studio 2008 and Visual Studio 2010 Beta2
- Moles (which includes Stubs), lightweight test stubs and detours for .NET
- API reference, tutorials and documentation
- Samples
The documentation is really detailed, and the samples are worth investigating. I quite liked the Pex Tutorial document, which explains in detail what Pex is all about.
The good thing is it supports many different testing frameworks, including .NET’s own, nunit, xunit etc. By the way, I have to say VS2010 is awesome!
Pex is pretty much like a unit test but better in many ways. I’m quite surprised by the dynamic coverage window of a test method that you execute. This way, it is clear to see if the code is fully covered by the Pex test.
Pex is more like test method that takes inputs. In general, unit tests are not taking any inputs, they are isolated from each other and from external access, other than calling them parameterless.
Input generation in Pex based on the static analysis of the methods. It generates inputs such that, the code will be covered in full, however for some special types, the inputs might need to be explicitely told to test framework. The tools it brings to Visual Studio is extremely simple and easy to use. It does a very good job on incorporating those results.
Here is a very simple function that I generated my first Pex tests from
public static int Compare(int i, string s)
{
if (i > 500)
{
i *= 2;
}
else
{
return Compare2(i);
}
return i * i;
}
When you run Pex, it generates potential inputs to cover all the code. According to the documentation, it uses static analysis to figure the potential values. So it is not a random number generated test, or a brute force test, which is quite interesting. Pex can cover some obscure side of the code, which fully supports many Unicode string inputs or regular expressions.
However, when I converted this very simple code, from System.Int32 to System.Numeric.BigInteger (a new type in .NET 4), the test only generated for a null value. Unless I’m missing something, it doesn’t support all the types as yet, but it looks like a promising and valuable product to be added to your toolset
A Feed You Should Read #23 – The Code Project
If you ask a developer how they like to learn new technology, techniques, etc nearly all will say, “The code, baby! Show me some code…!”
Today’s Feed is one of the premier sites for developers, by developers which revels in the code, baby!
Background:
I love The Code Project. I’ve found more cool things on this site than I can count. Almost every day there’s some project that I want to capture for future reference. Best of all is the fact that the articles are by developers, for developers.
How often have you used the Net to solve a coding problem, or to learn something? Yeah, like a million times. Me too. Yet were would we be if everyone was a consumer and no one a producer?
That’s what draws me to the Code Project, easy it makes sharing, to help you be a producer. You don’t need to be a “A Lister”, have a deal with a publisher/site, be a name in our field, a blog, yada, yada. You just need to desire, and code. Sharing a cool project, technique, solution to difficult development problem or bit of code is simple, easy and free.
The act of paying it forward is what gives this site its true power.
Why do I like this feed and think you might also?
Learn by seeing code?
Like to see people talk about and code cool stuff?
Code in in .Net, MFC/C++, ASP, C#, VB?
Want to give back a little yourself?
The Code Project is a site and feed for you…
Snap of the latest posts:
Blog Information:
Name: The Code Project URL: http://www.codeproject.com/ Feed: http://www.codeproject.com/webservices/articlerss.aspx?cat=1 (All Topics) Post Types: Development (aka Code) project articles (most with source)Related Past Post XRef:
A Feed You Should Read TOC
Now the Lab Management part of the Dogfooding story ….
In my last post I talked about how the Visual Studio Test and Lab Management teams are dogfooding those products – that is, as we enter the home stretch of the VS 2010 release, we are using the very same tools we are building, to test and sign off on the release. We are using the RC bits, and these bits will be broadly released very shortly. My team has already blogged about all of the changes that have gone into the RC version of the testing tools – you can read about those here.
In this post, I will focus on how we are dogfooding the Lab Management product, and are benefitting from it. This really highlights all of the coolness that you can expect to see, as you use the product too. Please refer to the last post, about the infrastructure and topology that essentially makes up “lab” that my team has setup using the Lab Management product.
The first diagram that I include below shows you a view of the lab in the “Lab” activity center of the Microsoft Test Manager 2010 tool.
You can see that, in this instance, the team is using 107 virtual environments for their testing (aside from another 80 physical environments). Each virtual environment is a logical collection of a set of virtual machines that make up the environment or configuration. For example, you can see that the highlighted environment is made up of four virtual machines (the view on the right side of the tool).
While this post is not about individual features in the product, let me take a moment to talk about virtual lab environments and what you do with them …
Setting up these virtual environments is really easy – we have blogged extensively about this at the team blog site. You can create a virtual environment by selecting a set of VM templates from the library. In the RC release we have added one more neat capability which allows you to compose a virtual environment from VMs that you may already have running on the host. Many of you, I am sure, are already using virtualization in your teams and likely have VMs (virtual machines) already setup. You simply need to install a few agents on those VMs and, with the RC release, can use this new compose feature to create a virtual lab environment. As part of the creation of the environment, you can also specify that you want the capabilities to automate tests and deployment of applications (for example, the applications under test) on to those environments.
Once you have created the environments, you can use the full repertoire of testing capabilities that we provide in this release on the environments. That in fact, is how we have been doing all of the testing that I talked about in the last post.
Getting back the diagram shown above – I want to highlight one specific benefit that I myself have experienced because of this dogfooding. While we have been building this product for the last couple of years, it was always a bit difficult to get a full view of all of the configurations and environments that my QA teams were managing in the physical labs. Now, with our product, I get a complete view of all of this from my own desktop, using the Microsoft Test Manager 2010 tool! This is just awesome for me as a manager. In the above view, I got to see the different types of environments that the team is using, and what makes up those environments. I can have multiple views on this.
The view below allows me to see which host groups the environments are part of …
… or I can view of which tester owns which environments
In another view, shown below, I can see when the environments were last accessed (I am using a screen shot from middle of November). This gives me a great sense of about the resource utilization in the lab.
The seamless integration of the Lab Center with the Test Center in the Test Manager tool is a very powerful interface to keep track of all aspects of what’s going on in your test labs, and I have personally enjoyed this myself.
The build-deploy-test capability of the product has also been a great hit with the team. This essentially allows you to define a workflow which can do the following:
- Schedule a build for the application under test. Once the build is done,
- Select a lab environment on which you want to do some testing using the latest build
- Restore the environment to a known good checkpoint (guaranteeing a clean state to begin with)
- Deploy the bits of the application under test onto the (multi-tier) environment
- Take a post-deployment snapshot, so that testers can return to a clean starting state for testing
- Automatically run a suite of tests on the above environment, and report results
A new build of the application is really at the heart of the entire development process. An ability like above takes away all of the inefficiencies and hand-off errors around the build, and will be extremely popular in development teams (for both testers and developers – who will use this mechanism to do their own types of testing on production-like environments).
The Lab Management product extends the Team Build functionality in TFS (accessed from Team Explorer) to provide the above capability. Below I show an example of a feature team using the above feature. Notice the “deployment summary” information page that is presented at the end of the workflow – it summarizes the various steps of the workflow and the results.
At this point, I must also highlight that the ability to customize the build-deploy-test workflow is an extremely powerful capability. You can automate various kinds of testing needs using this. My team has blogged about this here. The power of this was particularly evident in our own dogfooding experience. Remember, when we are dogfooding, the “application under test” is really VS 2010 and the same testing tools that we are using. So, the event of a new build being generated becomes particularly challenging for us. As part of the deployment workflow, the same agents which are orchestrating the workflow need to be upgraded to a newer version that is part of the new build! Doing this is no easy feat, for it needs reboots in the middle and a newer version of a component to complete a workflow that was initiated by the older version. And all of this is done automatically when a new build comes out! The test team has done a good job generating the scripts and commandlets to customize the workflow, and I was very happy to observe the flexibility and power of this feature in our product.
The diagram below also shows the power and flexibility in debugging where the problem is, when a workflow fails – particularly when the flow spans multiple machines, as it did in the above case. The logs generated as part of the workflow are extremely detailed, and organized in a nice fashion (highlighting the different steps, the time they took, and the warnings/errors generated) all in one place. This is a big improvement from the situation where testers have to manually look at logs in different machines individually to see what might have gone wrong. Here all of the information is in one log that you can access from your desktop, as part of the workflow summary information.
Features like noting the total elapsed time against each of the steps of the deployment workflow also helps a great deal in making the testing process efficient. For example, as shown above, it really helps the testers isolate which part of the workflow is taking the most time and see if those need to be optimized.
Before I sign off on this story, I want to return for a moment to the first diagram in this post. I am including it here again.
Notice the highlighted environment – “TeamLab-SelfhostLE-2” and the set of machines shown on the right hand side which shows what the environment is made out of. You can see that this environment includes a load balanced TFS server, a build controller, and a test controller. This in fact is one of the environments that the Lab Management feature teams are using to test the Lab Management product. This essentially is a sort of “recursive” use of the product within itself – pretty neat, isn’t it?
I hope this post and the last one has given you a good sense of the power of the testing tools that we are building, and the extent to which we have been dogfooding them to ensure that they are really ready for our customers. This dogfooding has been going on for more three months now, and the product is looking amazing solid.
The RC bits of VS 2010 will be released shortly. Setting up a Lab certainly needs more commitment of time and resources than trying out client side only features, but you can get started with a lab of just a couple of Hyper-V capable machines to see for yourself the power of the product and how it will take out the many inefficiencies that plague a typical dev/test lab. I hope this story give you the impetus to get going on the product. I would love to see a diverse set of customers go-live with the product and share with us their success stories, before I release the product.
Cheers!
A marketing mistake: WCF Data Services & WCF RIA Services
There are some things that I just don’t understand, and the decision to name two apparently different technologies working in the same area using those two names is one of them.
The image on the right is from In Search Of Stupidity, an excellent and funny book, which talks about a lot of marketing mistakes that software, dedicate a whole chapter for this error.
Coming back to WCF Data Services & WCF RIA Services, I read this page, and I am still confused. It appears that the major difference in that RIA services will generate the Silverlight client classes as part of the build process, where as using Data Services this is a separate process.
And I am not sure even of that.
Entity Framework Context Lifetime Best Practices
In this post I’m
going to write
about one of the
major decisions
that you need to
take when you use
ORM tools like Entity Framework.
This decision is the context lifetime.
Context lifetime is a very crucial decision to make when we
use ORMs. Since the context is acting as an entity cache (it holds
references to all the loaded entities for change tracking and
lazy loading purpose), it may grow very fast in memory consumption.
Also this behavior can cause a memory leak because if we don’t
dispose our context it will have references to all the loaded entities
and by that they will never be collected by the Garbage Collection.
Another problem that raise its ugly head is keeping a context lifetime
to long or to short. If we dispose the context after every database
manipulation or query we won’t enjoy the all the features it holds
(for example change tracking).
For example the following code disposes the context very fast and
shows the problem I talk about:
using (var context = new SchoolEntities())
{
context.AddToDepartments(department);
context.SaveChanges();
}
On the other hand, keeping a long running context is also bad practice.
Sometimes I see developers that use the context as a singleton in their
system. This is very bad since as I wrote it can cause a memory leak.
Also it is bad habit because you will have transactions for longer time
than you should have them. Business transactions and connection
management should be used in very short bursts and only as they are
needed.
- Web applications – use the context per request. Since in web
applications we deal with requests that are very short but holds
all the server transaction then they are the proper duration for
the context to live in. We will enjoy all the functionality of the
context and it won’t hang up very long. - Smart clients (Win Forms/WPF etc) – use a context per form.
Since we don’t want to have the context as a singleton for our
application we will dispose it when we move from one form to
another. In this way we will gain a lot of the context’s abilities
and won’t suffer from the implications of long running contexts.
Managing context lifetime is very crucial decision that we need to take
at the starting of every project. My rules of thumb is context per
request and context per form lifetimes.
ASP.NET redirect a web page with AJAX loading indicator image
Git: Remotes, contributions, and the letter N
Here’s a few ways to think about Git and it’s distributed nature.
- You deal with multiples of repositories, not a single central repository
- Updates come from a remote repository, and changes are pushed to a remote; none of these repositories have to be the same
- Origin is the canonical name for the repository you cloned from
- Upstream is the canonical name for the original project repository you forked from

Pushing your changes to a remote: git push remote_name

Pulling changes from a remote: git pull remote_name
Or if you want to rebase:
git fetch remote_name git rebase remote_name/branch
You can change your branch.autosetuprebase to always, to make this the default git pull behaviour.
That’s all there is to moving commits around in Git repositories. Any other operations you perform are all combinations of the above.
Github — personal repositoriesWhen you’re dealing directly with Github, on a personal project or as the project owner, your repositories will look like this:

To push and pull changes between your local and your github repositories, just issue the push and pull commands with the origin remote:
git push origin git pull origin
You can set the defaults for these commands too, so the origin isn’t even necessary in a lot of cases.
Github — receiving contributionsAs a project owner, you’ll sometimes have to deal with contributions from other people. Each contributor will have their own github repository, and they’ll issue you with a pull request.

There’s no direct link to push between these two repositories; they’re unmanned. To manage changes from contributors, you need to involve your local repository.
You can think of this as taking the shape of a V.

You need to register their github repository as a remote on your local, pull in their changes, merge them, and push them up to your github. This can be done as follows:
git remote add contributor contributor_repository.git git pull contributor branch git pushGithub — providing contributions
Do exactly as you would your own personal project. Local changes, pushed up to your github fork; then issue a pull request. That’s all there is to it.
Github — the big pictureHere’s how to imagine the whole process, think of it as an N shape.

On the left is the contributor, and the right is the project. Flow goes from bottom left, along the lines to the top right.
- Contributor makes a commit in their local repository
- Contributor pushes that commit to their github
- Contributor issues a pull request to the project
- Project lead pulls the contributor’s change into their local repository
- Project lead pushes the change up to the project github
That’s as complicated as it gets.


