July 2005 - Posts

VSTS and Security Best Practices
22 July 05 10:54 AM | MikeD | 1 comment(s)

I haven't had a chance to look at the new iteration of the MSF Agile process template for Visual Studio Team System, but I think I heard that there is a Risk work item type in it.

I got to thinking today as I was looking at a Chinese PPT slide deck for an MSDN web cast that my Chinese host presented yesterday (about 200 in attendance he said), as I was looking at STRIDE and DREAD, that really, security best practices should be a part of the MSF VSTS process template.

I think it would take the form of at least one work item type, and perhaps a test type as well (tho tests are not part of the process template).

"Defence in depth" should be integrated into the SDLC, a part of the process.

Perhaps someone else has said this already, and likely better than I have, if so, I add my voice to theirs.

 

Filed under:
Ascend Training in Beijing and VSTS stuff
21 July 05 10:05 PM | MikeD

I'm finishing up two weeks of teaching the Ascend training on Visual Studio 2005 in Beijing China today.

Each week we spent one day each on ASP.NET and SmartClient development, then had three days on Visual Studio Team System.

The students last week were mostly Microsoft China employees and some partners, and this week the audience was trainers from Microsoft Training centres outside of Beijing.

Last week, I was team teaching with Joe Homnick and Ken Miller, who had been in England the previous week and were very lucky to have missed the bombing attacks in London.

This week I was teaching alone, and of course it was a much more intense experience doing so. In all, it has been a tremendous experience here, my first time outside of North America, I have learned a lot indeed. My hosts have been very kind to me, one Microsoft guy took me for a whirlwind tour of Beijing tourist spots last Saturday, 13 hours in all. And last Sunday I went to the Great Wall. So, being away from home for two weeks has its benefits, too.

Anyway, the audiences here have been very interested in Visual Studio Team System. Of course, there is all the stuff around work item tracking, having the tools support your SDLC, great new features in source code control and testing, but what I found most interesting was the modelling tools. The Great Wall that divides the network/infrastructure guys and the developer teams is squarely addressed with these tools - having the infrastructure team create logical datacenter diagrams that describe the server environment and constraints in a way that is easily consumable by the solution architect is just huge.

And the fact that we can be clear about the environment that we will deploy into, and to validate that through a Deployment diagram which allows you to place components and applications from your Application or System diagrams onto a logical datacentre diagram, and do all of this well before we even think about transitioning to production, is great. The last major project I was involved in, we thought we had known sufficient detail about the target environment. Thank goodness we started trial deployments into that environment pretty early in the Construction phase of the project, and discovered the real differences early, otherwise our project would have certainly gone over time and under-profit. As it is, three months after we have completed the project, it is only this week that the customer has deployed the application into a productino environment there. Having the deployment scripting tools and these diagrams available to us would have saved considerable time and effort, and of course, money.

I have also had two opportunities to show Imaginet's Process Template Editor tools that we are working on. While current thinking around SDLC's is often around agility and continuous improvement, VSTS provides little real tools to modify the Process Template easily (export to XML files and folder structure, modify using your favourite XML editor, import into VSTS). And don't even think about modifying the schema of work item types on the fly.

Well, Joel, our boss, has recognized this and at Imaginet we are working on a Process TEmplate Editor tool that will read the exported XML files and folder structure and provide a nice editing tool to make changes. Included is a great Work Item Type Editor that allows for specification of fields, states, transitions, and the form layout, with a graphical preview of the form too.

The Work Item Type Editor can also be used separately and work against the Team Foundation Server directly, modifying work item types in a current instance of a VSTS project. This allows you to modify your tracking system on the fly. If you had a long-running VSTS project, like anywhere between 3 and 24 months or longer, the ability to tweak the process on the fly is so important.

When I show the raw XML of the process templates to students in this Ascend training, their eyes glaze over (It is Friday afternoon, after all), but when I then show them our beta Process Template Editor, their jaws drop, if I do say so myself (thanks for the great interface, Ben!) Even Ken and Joe and Ed Chang last week stopped what they were doing to see this.

So, are you interested? Of course you are. Stay tuned for further details at a VSTS event near you.

 

 

Filed under:
Debugging .NET Services
07 July 05 09:41 PM | MikeD

Not Web Services, but Windows Services...

First of all, writing a windows service is pretty easy (just start with the Windows Service project template) but testing it can be tough. It's better to write your logic in a separate assembly (and write NUnit tests to verify the functionality) and then add the Windows Service as a facade to that assembly.

Sometimes, though, you really wanna just break into the debugger while the service is running, right?

It turns out its not that hard to do:

  1. Add the service account that is used by the service to your local Debugger Users group (Computer Management/Local Users and Groups). Usually the service account is "Network Service" or "Local Service" or a specific account you have chosen to use.
  2. In your source code, add the following line of code wherever you want to break into debug mode:
    System.Diagnostics.Debugger.Break()
  3. Compile your service and install it (I'm gonna blog about installers and InstallUtil later).
  4. Start your service from a command line (Net Start MyService).

When the service hits the line of code inserted in Step 2 above, it will ask you if you want to debug the application, using a CLR debugger, the current instance of Visual Studio (this is what you want), or a new instance of Visual Studio. If you didn't get the right account in Debugger Users in step 1, you will get an "Access Denied" message instead of the question about debugging.

From this point, you will be able to step through your code and do your normal debugging.

Don't forget to remove the line of code that breaks into the debugger before completing your project! It's probably a better practice to use a compiler directive to ensure that you don't compile in the Debugger.Break() call into your release code.

In order to recompile your application (since you're debugging it, you're probably expecting to find some bugs, right?), you will have to stop the service and uninstall it again before re-compiling. I usually have two batch files that will help me do that: one to install and start the service, another to stop the service and uninstall it.

Happy debugging!

 

Filed under:
Back on the blog
07 July 05 09:14 PM | MikeD

Finally, I have figured out how to reset my blogspace password, so I can blog again.

Just in time for a trip to China, teaching Visual Studio 2005 and Team System in Beijing for two weeks, with Ken Miller and Joe Homnick. I'm looking forward to it.

 

Filed under:
More Posts