HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\Servers

So, to sum up the six easy steps are:

1. Check to see if you've already got Visual Studio 2008 Team Explorer - if you do skip to step 4.
2. Install Visual Studio 2008 Team Explorer
3. Install/Reinstall Visual Studio 2008 SP1
4. Install VSTS2008SP1FCUTFS2010
5. Add servers via Registry
6. Say hello to the future - flying cars and TFS 2010.

Today, I came across a need to programmatically rename IIS 7 Virtual Directories and Applications using C#.   Searching the web, I found several examples to add them, but wasn't able to find any to rename them.   By exploring the class methods and modifying the examples accordingly, I was able to come up with what I was looking for.

Rename IIS 7 Virtual Directory

     ServerManager iisManager = new ServerManager();
     Application app = iisManager.Sites["SiteName"].Applications["/"];
     VirtualDirectory vdir = app.VirtualDirectories["/OrigVirtualDirectoryName"];
     if (vdir != null)
     {
          vdir.SetAttributeValue("path", "/NewVirtualDirectoryName");
          iisManager.CommitChanges();
     }

Rename IIS 7 Application

     ServerManager iisManager = new ServerManager();
     Application app = iisManager.Sites["SiteName"].Applications["/OrigApplicationName"];
     if (app != null)
     {
          app.SetAttributeValue("path", "/NewApplicationName");
          iisManager.CommitChanges();
     }

If you want to work with a remote server, just change the first line to be

     ServerManager iisManager = ServerManager.OpenRemote("RemoteServerName");

I had to set up an SSIS package that inserted data into a log, grab that logID and pass it to all of the sub tasks so they can use that LogID.

I am new to SSIS packages and had to do a lot of reading to come up with how I was going to create an SSIS Package, Define a package variable, then pass that variable to a task. I set up a simple proof of concept to test my ideas.

First I Opened VS, and created a new Integrated Service Project. If you have a hard time finding it, it’s Project Types: Business Intelligence Project, you may need to install this from your SQL installation.

Next I Clicked on Tools->Other Windows->Variables. Making sure I have the SSIS Package I want to work with selected and in the open window I clicked on the icon for new variable. This was important because your variable scope can be pointed to a different project or at the task level if you aren’t paying attrition.

I gave it a common name, and set the Data Type to Object. This is set to object because I had an issue passing int32 values. I’ll talk about it below.

Now in my Control Flow I opened up my “toolbar” and dropped two Execute SQL tasks, I double clicked on the first one. Because this one will pass the ID to my variable I need to set the ResultSet to ‘single row’ then I am using an OLE DB connection, and put my localHost for the server.

Then I clicked on the SQL Statement ellipses and pasted in a very simple statement “select 8 as Test” this is just so I pass a value, in my real solution I had a bunch of sql code and ened it with “select IDENT_CURRENT('log.TaskRun') as TaskRunID” .

Now I have to bind “test” in my example or “TaskRunID” in my second example to the variable. I do this in the “Result Set” tab. I simply click “Add” (if you do not see add you did not set a value for “ResultSet”) For ResultName, this is where I put “Test” or “TaskRunID” for Varable Name it will look like User::<name>. Click ok and open the next Task.

For the second Execute sql task you will fill out the same information as before this time with a new SQL Statement.  For simple sake I put this
Declare @temp numeric
set @temp = ?
insert into log.taskrunlog (message) values (@temp)

Here I am jut inserting my value into the database, to show I did something.  Things to note is that I am declaring my temp as numeric, this was the only int style choice I could find. Also note the “?” this is used to denote variable in SSIS.  In my simple example I could replace @temp with the ? and only have one line of code, but if I wanted to reuse the ? I must put it in a variable. If I had 3 parameters then each ? will refer to a different parameter.

Next  lets click on the Parameter Mapping tab and click “add” from here you are going to select the variable name from the drop down user::<name> this is an input, data type is Numeric, next it very important Parameter Name is 0. If you have a list of them the next will be 1 etc. This allows the ? to work correctly.

From here you can right click and ‘execute task or f5 or click the green arrow. In my case I had to save it to the server first before I could execute my package, I can do that by file->save copy of testVarable.dtsx as…

From here I was able to create a task and execute it from sql, I’ll be showing that part next week.

So, how about that Silverlight?

After a rocky initial few years, Silverlight's become quite the tool for creating rich internet applications, not to mention Windows Phone 7 applications. It does this by bringing the power of .NET directly into the web browser, via a plug-in. This brings one huge advantage: Silverlight, at its core, is a client application. That's right, despite being delivered over the web, Silverlight apps are built very similarly to a client application. There's no special tricks keeping track of state, requests from the user can be handled by event handlers, and all that good stuff. It's much easier to make a well- designed application because you don't have to constantly worry about reinstantiating objects. This also means you are freed from the anti-pattern design of ASP.NET. So, what's the best way to make maintainable and reusable code in Silverlight? MVVM.

It works in WPF too, FYI, but I'm ignoring that for now.

The usual response to inquiries about MVVM is, "Yeah, I've heard about it," with the "What IS it?" being implied. This is partly because MVVM hasn't been well publicized, and that's partly because it hasn't really been standardized. So the simplest answer one can give to the question of "What is MVVM" is that it is a design pattern. I'm not going to diverge off onto what design patterns are, except to say that (as Captain Barbossa might say) it's more what you'd call "guidelines" than actual "rules." However, MVVM is more than a design pattern, it is really the design pattern to use in Silverlight. The reason for this is straightforward - it takes advantage of the unique relationship that Silverlight has between the Presentation Layer and the UI Layer. Silverlight may be a client app dev tool, but that doesn't make it a WinForms app dev tool. I learned this distinction. WinForms design patterns don't take advantage of that unique UI layer, but MVVM does.

It stands for Model-View-ViewModel, BTW

MVVM describes the relationship between the Model, View, and the ViewModel. The Model and the View are pretty easy to understand. The Model is your collection of domain objects, and your business logic. The View is where you display your Model, listing domain objects, and listing their attributes. The ViewModel is the real meat of the MVVM model, and is the reason that MVVM is so necessary to a Silverlight project of any complexity. Again, this isn't official, and it isn't standardized really (again, guidelines), but at its core the ViewModel is where you hold the databinding logic that connects your View to your Model's data. Now, this is relatively unique as far as Presentation layers go. Usually, if databinding is to happen, it can't happen in the Presentation layer because the Presentation layer is too far removed from the UI. So what ends up happening is either the Presentation layer and the UI are smashed together, or the databinding happens all in real time and debugging becomes a pain. However, Silverlight's UI has built in hooks to allow for databinding to another object. This entirely changes how the UI relates to the Presentation Layer, because now the Presentation Layer can basically be anything. In fact, if you wanted, you could connect the UI directly to the Model.

Wait, what? Why don't we just do that?

So why the ViewModel? Why MVVM and not just ... MV? Because, as you can imagine, the model is meant to contain ONLY business logic. And if all you were doing, ever, was displaying the attributes of your object, then that could work, as you'd have no presentation logic. For relatively simple Silverlight apps, that could work just fine, more than likely. That raises questions though - what happens when an artist wants to work on the view? What happens when you want to test the UI? What happens if you want one view to show data from multiple domain objects?

This is where the ViewModel comes in. It provides the databinding layer for your UI to connect to. And in this databinding layer you can pull from multiple domain objects, you can sort lists, page lists, split things up and combine things together for display on the view. And the best part? You can even display dummy data for design time. That's right! Now your designer won't have to just try to build something and wonder if that's going to look right. All he has to do is connect to the ViewModel, and dummy data shows up. Now the designer has something to design against, instead of just guessing. And he doesn't need to know any of the logic, because the ViewModel takes care of all that, and if something changes, he's not totally screwed because everything is loosely coupled. Trust me, on a project of any complexity (and even simple ones!) if you bind directly to the model you will eventually regret it. And then you'll have to make a ViewModel for just one View, and then your code is inconsistent and everything is ruined forever.

MVVM and Rapid Development

Like MVC and MVP, the slowest part of design patterns like MVVM is learning them. And like MVC and MVP, once you've learned MVVM, it is significantly faster than attempting to do it the anti-pattern way. Also, trust me on this one, it's signifcantly faster than pretending that Silverlight is old WinForms tech. (That gets you nowhere, slow.) Not only are these design patterns faster to develop against than just smashing code wherever you can, but they're more modular, they're more maintainable, they're easier (and quicker) to design against, and there's generally a lot less of going back and forth over the same code trying to figure out why it breaks every time you make a change. (Again, hard lesson on that one.) This means more time focused on adding new features, and less time trying to track down hard to fathom bugs. Also, there is a nice separation of interests in the code, which lets people figure out where things are faster. Combined with templating in Silverlight, this makes application development very quick.

So MVVM works well for rapid development - once you've learned it. But it's very much worth learning. On a side note, what about rapid development with RIA? Well, that's another post. But yes, it does work with RIA.

Man, so Microsoft must have totally built MVVM right into Silverlight! Err...Right?

So, hey, builtin stuff, yeah. That's most likely coming in Silverlight 5. There is a good reason that MVVM hasn't yet been built into Silverlight - it isn't that old, in all honesty, and it's still being developed, even in terms of theory. And more so, if Microsoft does include a solution, it has to be a solution that appeals to almost everyone. So it's taking a little bit to get to that point.

So in the meanwhile, there are various MVVM frameworks that have been built. The only one I've used so far is MVVM Light, developed primarily by Laurent Bugnion of Galasoft. Now he designed this framework with "Blendability" in mind. That is to say, working with designers who are using Blend is the foremost concern. He readily admits that if you are looking primarily for testability, or have other concerns, MVVM Light might not work out for you. There's also Caliburn and MVVM Foundation. Also, as mentioned earlier, MVVM isn't just Silverlight, it's also WPF. In fact, almost all the frameworks mentioned above support both Silverlight and WPF applications. So really, by learning MVVM you're getting a twofer on app skills. So hopefully, if someone out there is wondering why MVVM is useful, this has helped answer that question. Now you're wondering, hey, heavy on the "why", light on the "how", right? Well, that would quadruple this article, so I'll just post some links to others who have already written about it. Dan Wahlin, Shawn Wildermuth, and for WPF focused, Josh Smith.

Questions and comments welcome below.