I’ve been using VS 2005 Beta 1 on a project, and the build seems to be a bit slow on starting, but there is a new context menu item called “Make”.  As far as I can tell, it builds the project just the same, and it does it WAY faster than “Build” or “Rebuild”, so that’s what I’ve been using to avoid waiting for the delay.  The bugs are currently being worked out of the build process, so I’m sure it’ll get faster. 

It’s working well.  My team has an extensive v1.1 team framework of common functionality, so since I’ve been developing a web app with ASP.NET 2.0 Beta 1, I’ve started on a v2.0 team framework.  Right now I only have 3 new classes, and I just reference the rest of the framework through the v1.1.  It works well, but there is one caveat.  When  used by the client application, you need to have all required .dll files in the bin folder, so we have our version 1.1 framework “TeamFramework.dll” and the v2.0 compiles to TeamFramework.dll also, so what to do?  Well, the easiest thing for me is to set the v2.0 project to compile to TeamFramework2.dll, but that was an issue.  Now, of course, putting these in the GAC would solve this problem, but our application doesn’t require the GAC.

All in all, the two versions inter-operate very well.

I realize that in small companies, the developer also has to be the System Engineer and is completely responsible for the server, but in larger enterprises, these responsibilities are assigned to dedicated teams.  As an enterprise developer, I’m on a team that develops and applications, deploys it and supports it.  We have an SE and DBAs that are responsible for maintaining the actual servers, but sometimes support issues get come to us when they really should be the responsibility fo the SE or DBA.  Suppose a database job fails, shouldn’t the DBA be responsible for that?  The code didn’t change.  What if an application server mysteriously stops responding in production?  Is it the SE’s responsibility to determine root cause?  These are issues facing my organization, and I’d like some feedback regarding your teams and your interaction with your SEs and DBAs.

The MSDN Product Feedback Center is looking for feedback.  Please provided feedback concerning how Whidbey can be made better before RTM.  If you are using it, please log bugs and suggestions.

Earlier, I blogged about using controls that are embedded in unusual places in the control tree of the DataGrid.  For instance, putting a LinkButton for adding a new record in the header or footer of the DataGrid.  You have to manually manipulate the Controls collection to do this. 

Another issue is what if you put that LinkButton in the same column as the Edit, update, cancel, delete buttons?  If you want to restrict editing of the data, a step on the UI would be to hide that entire column.  Seems pretty straight-forward, but how do you get a reference to that column?  I searched, and the only way I found was to reference it by the index in the Columns collection:

dgd.Columns[7].Visible = false;

That works well, but it bit me in the butt when I tried to maintain that code.  Down the road it became necessary to add two columns to that DataGrid.  Then, you guessed it!  A nice, little bug in my code.  Usually I’m able to avoid the debugger in VS by writing modular code and using the heck out of the ASP.NET Trace feature (great for code maintenance), but this was an issue that actually required a breakpoint.  Once inside the code, it was very clear what was happening.  I changed the index to the new index of the edit column, and my problem was fixed (until next time), but isn’t there a more maintainable way to do this?  What happens when another developer needs to modify my application.  Yeah, I document the heck out of it, but why can’t the Columns collection support column name identifiers as well.  I know the answer (CollectionBase), but it would be nice.

For now, I’ll have several lines of comments above that code. 

I recently downloaded and used Lutz Roeder’s Reflector program, and it is a pretty sweet tool.  VS 2005 Beta 1 has the class browser just like VS 2003, but the disassembler is what make Lutz’s tool so useful. 

The disassembler takes the compiled MSIL and converts it back into its best guess of C# or VB or Delphi (you can also view the IL).  Using that guessed code (which is VERY accurate), you can find out how a method was implemented.  It can be used on .Net Framework types as well.

It saved me a lot of time just today.  I knew I need to use a certain object in a predefined assembly, but I didn’t know how the class was intended to be created.  There was a constructor with parameters for all the things that needed to be populated, but I didn’t know all that information.  Using the disassembler on another class in that assembly that used the object in question, I was able to see that a completely different object is in charge of instantiating my said object.  Now, I can easily creat my mystery object, and Lutz has saved me time.  Thanks!

In .Net 1.0 and 1.1, we got used to creating a private constructor if we wanted to prevent someone from creating an instance of our class.  If we did not define a constructor, the default constructor was compiled for use, and the user could create an empty instance.  So we prevented this by creating the private constructor.  In C# we have classes, but in VB, there are classes and then modules which can contain only static (Shared) methods.  In .Net v2.0 Beta 1, C# can have the static keyword applied to classes to prevent them from having instances.  Now, I’ve deleted my private contructor and applied the static keyword!  There’s not going back now!

For those of you who use FxCop, beware of version 2.0.  Actually, look forward to version 2.0 and jump for joy, but it would benefit you to learn about version 2.0 now so that you can prepare to move to the next version.  I’ve migrated some v1.1 code I wrote last year to v2.0 Beta 1.  I had run FxCop on my assembly last year, and I decided to follow all the Microsoft Recommended conventions.  That included NOT using the default overload of the .ToString() method.  Instead, I was supposed to use the overload that specifies an IFormatProvider, so for most of my code, I used ToString(CultureInfo.InvariantCulture), and now in VS 2005 Beta 1, I am getting warnings:

Warning 3  ‘System.Enum.ToString(System.IFormatProvider)’ is obsolete: ‘The provider argument is not used. Please use ToString().’ C:. . .Visual StudioProjects. . File.cs 617 64   

I thought it was a pain to specify CultureInfo.InvariantCulture for every call, but I went along with it.  I guess the MS people decided to agree with me.  🙂

I’m actually glad about this change.  Seems like most v2.0 changes are for the better. . . . but I still take issue with not having a concrete assembly in web site projects – we need a way to configure what the dynamically compiled assembly will be called.

I invite you to visit the VS 2005 Beta 1 Developer Center.  You can submit suggestions and bugs to the VS 2005 team.  I’ve submitted several bugs already and made a suggestion.  Two of my bugs have been validated, and another was a duplicate.  Hopefully my bugs will be fixed in the Beta 2.  Either way, I’ve done MY part to ensure that the IDE I USE is the best it can be. 

The web.config file in ASP.NET enables configuration of the entire ASP.NET application.  It is a file that is part of just about every ASP.NET application, yet I see many developer who roll their own configuration schemes beside the web.config file instead of making use of the functionality already built in.  Yes, some may use the appSettings section and then just retrieve a value from a key, but web.config can do so much more than that!  Here is a sample of how easy it is to add your own configuration section, thereby partitioning a section of configuration items away from the others:

<configuration>


   <configSections>


      <sectionGroup name=”MyCompany.MyApp.MyNamespace”>


         <section name=”SomeClassesConfig”


            type=“MyCompany.MyApp.MyConfigHandler“,MyCompany.MyApp” />


      </sectionGroup>


   </configSections>


   <MyCompany.MyApp.MyNamespace>


      <SomeClassesConfig>


         <add key=”myKey” value=”myValue” />


      </SomeClassesConfig>


   </MyCompany.MyApp.MyNamespace>


</configuration>

Then, in your code, you just have a class, MyCompany.MyApp.MyConfigHandler that inherits from System.Configuration.NameValueSectionHandler, and that’s all it takes.  If you don’t make your own ConfigHandler, then you have to specify the strong name in your type=”” attribute, and not only is that painful, but when you migrate this code to .Net 2.0 and beyond, you will have to modify every place where you gave a strong name.  If you make a superclass of it, then when you migrate the superclass, you’re golden.

To get to these values in your code, you just use a NameValueCollection that you can get from calling:

ConfigurationSettings.GetConfig(“MyCompany.MyApp.MyNamespace/SomeClassesConfig“);

Does that look like an XPath expression to you?

You can further extend the web.config file with your own ConfigHandler that has nested XML elements instead of just a key and a value.  You could store complete object information in the web.config (if the data rarely changes).  Remember that every change of the web.config forces a restart on that directory and its children.

Coming up in May of next year, .Net 2.0 will have the APIs to modify .config files programmatically.  Check out the Beta 1 to use this functionality right now.