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.

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.


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.



I have an issue with the DataTable object. Although I think it's a cultural thing. Some people I talk to don't seem to bothered by it. I find it very annoying, mostly because it would have been so easily avoided.

So whats the problem? When a DataRow is flagged for deletion it's still part of the row collection in the DataTable. So you may now be wondering what the big deal is.

You see I spent 10 years in the PowerBuilder world. In a PowerBuilder DataWindow (Similar to the objects in ADO.NET) when a row is flagged for deletion it's stored in a separate collection. Therefore when you are processing the rows The Deleted rows are not in the collection of current rows. If you want to access the deleted rows you can do that also. Also when you get a count of rows it's the count of rows not including the deleted rows.

In a DataTable when you delete a row it remains in the rows Collection and you have to deal with them. This also means that DataTable.Rows.Count or DataTable.Count is a count of all the rows including deleted rows.

Why do I say it's cultural? My esteemed colleague Bruce Johnson and I had a brief discussion and he almost convinced me this is how it should be. Bruce said "It's only flagged as deleted why shouldn't it be in the Rows collection?"  I have to say this is a fair statement. However it would make life easier for the developer if there was a DeletedRows collection. Therefore a corresponding DeletedRows.Count. This feels more natural to me.

When do you ever want to iterate through all the rows in a DataTable both deleted and not and preform the same action on them? I could make something up but it would be bogus. I have never wanted to do this. Even if you can come up with a good reason it's not going the be the common scenario. When you write a framework you should take into account the 80/20 rule. Make it easier for 80 percent of the cases and let the 20 percent do extra work.

This means that when you iterate through a collection of rows in a table you have to be sensitive to the fact that some of them may have been deleted.

There are ways to make life easier, and when .net 2.0 (Whidbey) comes along there will be even more.

What can you do about it?

You could check the row state inside your iterator like this.

For each row as dataRow in DataTable
          if Datarow.RowState <> dataRowState.Delete then
          end if

Or you could get a subset of the collection like this.

For each row as dataRow in dataTable.Select("", "", DataViewRowState.CurrentRows)

Keep in mind with this solution if you are using a typed DataSet you will have to cast the select for the typed row.

For each row as OrderRow in Ctype(OrderTable.Select("","",DataViewRowState.CurrentRows), OrderRow())

I recommend wrapping up the select in a DataSetHelper method, so it looks like this.

For each row as OrderRow in Ctype(DataSetHelper.GetCurrentRows( OrderTable ), OrderRow())

What about getting the count of Current rows in the DataTable. You could wrap this little code segment up in a method in your DataSetHelper also. Just pass in a DataTable.

Public Function GetRowCount( dt as DataTable ) as integer
              Dim dataView As New dataView

             dataView.Table = dt
             dataView.RowStateFilter = DataViewRowState.CurrentRows
             return = dataView.Count
End Function

I mentioned above .net 2.0 (Whidbey) will help. How is that you ask.
There are a couple of solutions.

  1. Using Partial types you could extend the DataSet Class to include a method that returns a collection of Current Rows. This way it's more natural to the developer.             OrderTable.CurrentOrderRows
  2. Using Iterators you could write your own iterator that only iterates thought the current rows.





Merry Christmas

I would like to wish everyone a happy holiday season.


Rename a XSD

Yesterday I tried to rename a DataSet. To lazy to recreate it. Have you ever tried to rename a DataSet?

It seems easy enough. Press F2 in the Solution explorer and type in a new name. Open the XSD and do a find and replace of the old name with the new name, there done right?

Not exactly when you try to generate the class it may get generated with the old name. Your solution ends up looking like this:

  • MyNewDataSetName.xsd
    • MyOldDataSetName.vb
    • MyNewDataSetName.xsx

So what is the solution? The problem is in the Project File. There's an attribute on the file node called LastGenOutput it is holding the old DataSetName. See below.

Delete this attribute and you will be fine.

          RelPath = "MyNewDataSet.xsd"
      BuildAction = "Content"
      Generator = "MSDataSetGenerator"
      LastGenOutput = "MyOldDataSet.cs"


Visual Studio Command Prompt

Here is another useful tip from Mark Comeau, this guy needs his own Blog. Then again I'm glad he hasn't got one. What would I write about. :)

Do you find yourself in the Visual Studio Command Prompt from time to time? Of course you do. Do you get to it via:

Start->Programs->Visual Studio .Net 2003->Visual Studio .Net Tools->Visual Studio .NET 2003 Command Prompt

Hopefully you have a shortcut that is closer to your desktop or start menu.

When you open it what directory are you in? Do you have to then use your vast knowledge of command line directory traversal to get to your source code or whatever it is your looking for?

Would you like to right click on a directory in windows explorer and open a Visual Studio Command Prompt already set to that directory?

Just add these entries to your registry:

@="Open VS Command Prompt Here"

@="cmd.exe /k \"C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Common7\\Tools\\vsvars32.bat\""

If you would like the same functionality from a Drive also add this to your registry.

@="Open VS Command Prompt Here"

@="cmd.exe /k \"C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Common7\\Tools\\vsvars32.bat\""

Thanks Mark thats a good one.


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.


Source Safe Performance

Here are a couple of good tips for making source safe run a little better over the network.

I have seen these before but a client (Mark Comeau) recently reminded me of them.

  1. Change your VSS Folder for temporary files to be local. It will default to where the VSS Database is installed. Tools->Options...-> General Tab
  2. Put your ss.ini on your local machine. This file normally is in the \users\ You can move it locally and change the \users.txt file to tell Source Safe where you put it.

Less network chatter means a better response time when using Source Safe over the network.




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.