Visual Studio Command Prompt

This is a trick I got from Paul Murphy at the Toronto Security Briefing. Which was very good by the way, I thought Paul did a great job. If you missed it and would like to see the slides and demos. Visit Paul's Blog he posted them last night. http://www.paul.bz/blog.aspx.

Back to the tip. You would think after a Security briefing my tip would be about security. But to be honest I need time to digest some of the tons of information presented.

This is a really simple little thing I knew how to do but never thought to do it.

As a .NET developer it is inevitable that you will be opening the Visual Studio Command prompt to run some command line utility. Weather it's Sn.exe or GacUtil.exe or one of the many other utilities you can run from the command line. It is suggested (with good reason) that you develop logged in as a regular user, not administrator. If you are developing as administrator there is a good chance when the application is run by a non administrator there will be code that will not run due to the difference in permissions between the two accounts.

Wouldn't it be nice if the Command prompt looked different when you opened it as administrator. So you know visually right away that you are in that session as an administrator.

Here is how to do it:

  • Open the Visual Studio Command Prompt
  • Click on the Command Prompt icon (Control Box) and select properties
  • Click the advanced button
  • Select Run with different credentials (When opening a command prompt you will no be prompted to log in as another user)
  • Click OK and then switch to the colors tabs.
  • Select another background colour for the command prompt. (You can change what ever you want about the command prompt as you visual cue)
  • When you click OK on the properties dialog you will be asked if you want to Apply changes to just this window or Modify the shortcut that started this window. Select the second option.

From now on when you open the Visual Studio Command Prompt as Administrator it will look different than the normal Command Prompt.

Thanks for the tip Paul.

Upstaged by Ballmer

So it would seem I'm upstaged by Steve Ballmer who is coming to town the same day as the CTTDNUG presentation I was making about Whidbey.  So in the interest of the greater good - my talk has been postponed until Mar 31.

The “Ballmer Developer Briefing” is mostly about Security...if that interests you?

What do you mean “IF” - of course that should matter to you. It should matter to everybody. Writing secure code isn't just about logging in you know. It's about keeping your code safe and more importantly your end users machines and data safe and not allowing your software to act as a gaping hole into their system or data be it through spoofing or SQL Injection Attacks. Writing code these days is more of a liability than it ever has and we all have to be responsible - so do yourself and the rest of the world a favour and brush up on your knowledge of security. Either that, or hire a good lawyer.

I'm so convinced this is a an important event (and sorry that I had to cancel my presentation) that ObjectSharp is co-sponsoring a bus for members of the CTTDNUG that will travel to Toronto from Kitchener and back. And for those of you no where near Kitchener? Did I mention that parking is free?

See you there.

Active Directory Application Mode

I haven't had much chance to use many of the cool things in Windows 2003 to date, but one of the new things (that incidentally also runs on XP Pro) is a new mode of Active Directory called Application Mode - in total ADAM. I'm finally getting to do some real playing around with this for a large application I've just started working on for a client.

It's basically a standalone active directory that is ideal for storing your own users and roles etc. to be used by your application in an active directory style - even if your company isn't using active directory. If you do go to AD down the road - it's a simple migration for your app. ADAM also acts as an LDAP server as well which makes it a bit more open. You can really put whatever you want into ADAM as it's schema is extensible (not unlike Active Directory). The idea though is that you can have multiple instances of ADAM installed on your server - each containing data specific to a unique application - while AD would store more globally required data throughout the enterprise.

It's pretty typical to store this type of application specific data historically into a SQL database. While that's possible, ADAM - and more specifically the underlying AD is more geared to this type of data. A relational DB remains an ideal choice for transactionally updated data, but ADAM is a great place to store any kind of administrative data that is, for the most part, written to once, and then read frequently by your application.

I'm going to be playing more with this, and specifically doing some performance testing and seeing what kind of improvements can be made by using it in the middle tier, caching some of the data in a wrapper object that is hosted in COM+ and pooled.

As an aside, I find it kind of strange that Whidbey - and specifically the new ASP.NET membership/roles stuff that is built in doesn't use ADAM - but instead opts for the classic database solution. Fortunately the membership/role model in ASP.NET Whidbey is an extensible provider model so I may just take a crack at creating my own provider that uses ADAM.

I should probably google that now as someone has probably already been there and done that.

Whidbey

So far so good.

When we last met I had installed Whidbey and the .net framework 2.0 on my production machine along with VS 2003 and 2002.

I haven't found a problem yet. I gave a demo at the CTTDNUG last Wednesday and it went OK. Well nothing went wrong that I didn't expect to using alpha software.

Also since then I have been developing an windows application in 2003 with no problems.

Not sure what will happen when I try to upgrade to Beta.

 

Whidbey and VS .Net 2003

Well I've done it. They warned me not to but I did it anyway.

I installed Whidbey on my machine along side 2002 and 2003.

I'll post any trouble I have right here.

Dave

Partial Classes

I'm really liking this idea of Partial Classes that is coming in .Net 2.0.

When I first heard about it, I thought “now that is going to be confusing“. But I've been playing with it in Whidbey and I think it's going to be cool. Both VB.NET (When do we get to stop calling it VB.NET and just call it VB again)  and C# allow you to split your class across two files. Although the syntax is slightly different.

C# - Each part of the class has the same definition as seen below

  • public partial class MyClass
  • public partial class MyClass

VB.NET - There is a main class and all others expand on that like this

  • Public Class MyClass
  • Expands Class MyClass

For those who are wondering, The two files must reside in the same assembly. They are actually combined at compile time.

I have been thinking about how useful this will be. Here are some of the uses I can see for Partial Classes.

  1. That section of code generated by the designer that you shouldn't touch, can go in another file (And in Whidbey it will)
  2. Extending a Typed Dataset or any other auto generated class (This is the same basic reason as number 1)
  3. Code Behind, I assume the ASP.NET team will use partial classes to implement code behind
  4. Multiple developers, two developers can work on different areas of a class at the same time without worrying about merging changes. Therefore it could be used to logically divide a class, think of it like regions on steroids.

What else? I'm curious to hear about others peoples ideas for Partial Classes.

 

XAML IntelliSence Patch for PDC "Whidbey" & "Longhorn"

Overview The IntelliSense in the PDC bits while editing XAML had problems inside Style elements as well as when completing tags and reformatting. This patch addresses those issues to improve the developer experience.

System Requirements
PDC '03 release of Longhorn
PDC '03 release of Visual Studio .NET "Whidbey"

Download: XAML IntelliSence Patch for PDC Visual Studio .NET Whidbey

Whidbey

Next Tuesday (Dec 9th) Object Sharp is hosting a free half day seminar on VS.NET 2.0 (Code Named Whidbey).  We'll show a lot of the new features in the IDE like snipits, expansions, snap lines and smart tags. We'll show you new features in C# and VB.NET, also ADO.NET and ASP.NET.

I think you will really enjoy this informal look at the next wave from a developers perspective.

Come on out. It's free and you just might learn something. You can register here.

 

.NET 2.0 Whidbey Presentation in Toronto

On December 9th, myself and Dave Lloyd will present an in depth sneak peak of the next release of .NET: Visual Studio .NET 2.0 (code-named "Whidbey"). This should be a really fun presentation but seating is pretty limited. Adam Gallant from Microsoft is going to come by and also demo Longhorn and Avalon. He's getting daily builds so hopefully he'll show us some cool stuff that wasn't in the PDC build and is maybe even newer than some of the stuff they showed us at PDC. Hope to see some of you there.

NAntContrib "slingshot" vs. NAnt "solution"

I was trying to build the latest NAntContrib project so I could take advantage of their Slingshot task which automagically converts a visual studio solution (*.sln) and projects (*.csproj - not sure about *.vbproj) into a handy-dandy NAnt *.build file complete with all reference, source inclusions, dependencies, debug, release, and clean targets. Nice.

The only problem with this approach of course is that you need to run it daily if you don't want your NAnt builds to break when a new project or reference is added to your solution. Fortunately, NAntContrib exposes slingshot not only as a command line tool but also as a native NAnt task. The pain is that NAntContrib doesn't have a “stable release” but only a “nightly build”.....which of course is not built against the NAnt “stable release”. So I had to throw away my NAnt stable release that I've been using and opt for the latest nightly build for it too. After I got both to compile successfully I started to battle goofy slingshot issues like having to map web projects to my local hd path, avoiding spaces in my paths, and ReallyReallyReallyLongPaths.  I ended up doing a subst to map a directory to a drive letter to make it short. All this to create a build file that will get thrown away each and every night.

While browsing through the new things added to NAnt since the stable release I was accustomed too, I discovered a new task “Solution”. It compiles a whole solution - sln file. No generation of a build file. My build file literally goes from hundreds if not thousands of lines to this.

<target name="Debug">

<solution solutionfile="ObjectSharp.Framework.sln" configuration="Debug" />

target>

This compiles our entire framework, with all 8 projects as referenced in the sln file, in the right order, with the same dependencies used by a developer while using the VS.NET IDE. What a concept: share the build files used by your build server and IDE so that there are no surprises or impedance mismatches. Such a great idea that MS is doing this with MSBuild in Whidbey. I wonder if MSBuild will have add on tasks like NAntContrib, like for Visual Source Safe, sending email, running NUnit, and executing SQL. I like my NAnt - not sure if I'll be able to break free with MSBuild.