Monday, November 05, 2007

Sweet Zombie Jayzus, how is it that in the year 2007, we are forced to deal with a screen such as this?

In the name of all that is hillbilly, WHY CAN'T I SORT THIS LIST?!? I've had to break out the calculus books to try to figure out the algorithm used to display this monstrosity and as far as I can tell, it is proof positive that computers can in fact generate true random numbers.

For the record, I wanted to add an app.config file to my project. You don't see it here because it's listed at the bottom as Application Configuration File. Nested 'twixt VBScript File and MDI Parent.

On a side note, don't ask me how I know but I'm positive that the entry for "Database Unit Test" is going to show up in my nightmares tonight.

Kyle the Becalmed

Saturday, October 13, 2007

Strolling through some Visual Studio tips courtesy of Chinh Do. Some good tips although some go away with ReSharper (and we won't get into the part in Tip 4 where he says "Regions [are] a great way to organize your code".

For now, I'll focus on Tip 6: "Attach to Process" to Start Debugging in ASP.NET. A quick summary: If you already have the application running in a browser, you can "attach to process" rather than pressing F5 to compile and run the app. The idea being that you don't need to launch your application and navigate to where you need to be.

Here's my own preferred method which goes along the same lines. Like Chinh, I launch the application in its own browser. (Side note: Usually this means creating a separate virtual directory for it in IIS but if you want to use the built-in web server (Cassini it's called, yesno?), you will have to launch the app from Visual Studio at least once to start the web server.)The next step is creating an empty html page and setting it as the startup page.

That's pretty much it. With this setup, you can play around with your code, re-compile (Ctrl+Shift+B), then refresh the browser to see the changes. Like Chinh's tip, there is no need to press F5 to launch the app, then navigate to the page to see your changes.

And you can still debug in this method. That's what the blank startup page is for. Launching the app will attach the debug process to your existing browser instance (as well as the instance that is launched when you press F5). So if I do need to step through code on a page, I can set a breakpoint, press F5 to attach the debug process, flip over to my existing browser and refresh the page to hit the breakpoint. The blank startup page serves essentially as a launching pad.

The advantages are pretty much the same as in Chinh's original tip. With my method, it's easier to attach to the debugger because all I need to do is press F5, rather than Alt+D, P, "as", Enter (which, truth be told, is still pretty quick). With his method, you manually stop debugging (Shift+F5). With mine, you can still do that or you can close the startup page to do the same thing (at least in IE, Firefox doesn't do the same thing).

Having said that, Chinh's method has one serious advantage over mine (and over debugging with Visual Studio using F5 in general): It doesn't matter which browser you use. If you want to use Firefox, you don't need to muck with Visual Studio to set it as your default browser. You can launch your application in both browsers, attach the aspnet_wp process, and refresh either one (or both) and your breakpoints will be hit.

So with that advantage in mind, along with some other minor quirks in my method, I'll be switching over to his "Attach to Process" for the time being to see if it makes things easier.

Kyle the Detached

Tuesday, September 18, 2007

I'd like to think the developer who put this error message into Visual Studio had a good chuckle while he or she was doing so:

Kyle the Unattached

Thursday, August 30, 2007

Having been having a merry old time moving projects around in our solution in Team Foundation Server. We had a few that had strayed from the folder where they were supposed to live and we can't have free-thinkin' VS projects now, can we? Anyway, there was a bit of a learning curve involving more than one rollback. Plus I coined at least three new words and phrases but it's all good now, as the kids say. So forthwith is my guide to doing the same in your project (as in your software project, not your Visual Studio project, rather your Visual Studio solution, I'm...ummm...rambling, aren't I).

Underlying guidelines:

• One at a time. Don't try to get cocky and move all your projects in one shot. You'll save yourself days of pain if you move them individually within one "check-in" session. (OK, maybe not *days* of pain but certainly precious minutes.)
• Rebuild and run your tests often. After you re-add your projects, before you check in, after you re-get the latest version, pretty much every second step of the process.
• If at all possible, make sure everyone has checked in pending changes, *especially* if they have stuff checked out in one of the projects you intend to move.

Now to the heart of the matter:

1. Make sure you have the latest version of the solution and have nothing checked out.
2. Rebuild and run your tests.
3. Remove the project from the solution. TFS should check out any projects that have a reference to the one you just emasculated.
4. Physically move the project to where you want it to be in Windows Explorer.
5. Re-add the project to the solution. It will be marked as "not under source control" which is a bit of a lie.
6. Loop through each project in the solution checking to see if it has been checked out. This is your indication that the project has a reference to the one you just moved. Re-add the reference to the moved project.
7. Re-build and run your tests.
8. Open the "Change source control" dialog. (Alt-F, R, O)
9. Unbind the project you just moved and click OK. It should be easy to find as it will be marked as Invalid.
10. Add the project back to source control. (With the project selected, Alt-F, R, E.) With any luck, TFS should add it in the appropriate path, adding any necessary folders along the way.
11. Re-build and run your tests.
12. Check-in your changes.
13. Re-build and run your tests.
14. Open the Source Control Explorer (from Team Explorer) and find the project in its old location. Delete it and check-in your change.
15. Re-build and run your tests.
16. Repeat ad infinitum.

One thing to watch out for is references to third-party assemblies. When I re-added our data access project, the compiler complained about a couple of NHibernate methods not existing. I dropped and re-added the NHibernate reference and they went away. If I had to guess, I would say that I have an old version of NHibernate in my GAC which the project tried to use after I moved it.

Kyle the Gatekeeper

Monday, August 27, 2007

How's this for obscure? Our solution contains a .dbproj file, which for those not in the know (including me up until about three days ago), is a type of project that is added when you install Visual Studio Team System for Database Professionals (pka DataDude after the legendary surfer that built it). We also use Cruise Control on a build server which does *not* have Visual Studio Team System for Database Professionals installed.

The issue was that the build would fail on the build server because of some reference to VSDBPro in the dbproj. Specifically:
D:\ccnet\projects\CritterClassifier\Source\Database\EHTDB.dbproj(75,11): error MSB4019: The imported
project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\TeamData\Microsoft.VisualStudio.TeamSystem.
Data.Tasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and
that the file exists on disk.

No problem, says you, why not simply ignore the project in the configuration that the build server uses? Well, says I, don't be actin' all high 'n mighty 'til you gone done tried it yerself! If you do, you'll discover that the error still occurs, although it doesn't actually cause the build to fail. (Yeah, it sounds whacky but I ain't elaboratin' so you'll have to try it to see it in action.)

The error doesn't actually occur when the project is compiled, mostly because the project isn't compiled during the build. It happens when the .dbproj file is loaded. (NOTE: We're using msbuild against the .sln file.) Opening the .dbproj file in a text editor, you'll see:

 <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v8.0\TeamData\
Microsoft.VisualStudio.TeamSystem.Data.Tasks.targets" />

My fix: add a Conditional attribute to the <Import> element:

 <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v8.0\TeamData\
Microsoft.VisualStudio.TeamSystem.Data.Tasks.targets" Condition="Exists('$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v8.0\TeamData\
Microsoft.VisualStudio.TeamSystem.Data.Tasks.targets')" />

This tells whomever is parsing this sucker not to import the project if the file doesn't exist. Of course, you won't be able to compile the project in this case but the build server doesn't need to know that...

Kyle the Finagled

P.S. Another potential fix is to compile the projects with NAnt instead of MSBuild, which I think is preferable if you can get away with it.

Wednesday, August 01, 2007

Test time, kiddies!

Assume that in the image below, we are looking at a class in Visual Studio with the default font and color scheme (except using Consolas as the default font). Also assume that ReSharper 3.0 is installed.

Locate at least three things wrong with the formatting on this screen.

First correct answer wins the opportunity to tell me how the &*%$ to fix it. Hint 1: Re-installing ReSharper has no effect. Hint 2: Changing the font/color setting for Tracepoint - Mapped (Enabled) will, for whatever reason, affect the same change in the variable "mockery" in the image above.

Kyle the Bemused

** Update **

Stop with all the responses already. It's embarrassing. You'll inflate my already-ballooning ego.

The three bits of freaked out formatting are:

• The mockery variable is formatted as if it is a breakpoint. However, after testing various settings, it is, in fact, formatted as a Tracepoint. Yeah, I didn't know what a tracepoint was either.
• Line 14 is not highlighted as a breakpoint.
• Line 15 is missing the closing semi-colon and the IDE has not picked this up as an error

There are two possible solutions. The first is to uninstall Visual Studio Team Edition for Database Professionals (p.k.a. DataDude). The more correct one is to install the latest service pack for Visual Studio, of which I had none.

Sunday, May 07, 2006

You'd think I have nothing better to do on a Saturday night. You'd think right...

I have attached, for your viewing pleasure, the settings file for my installation of Visual Studio 2005. Recently re-configured because uninstalling ReSharper left them in such a state and I had to reset and rebuild them. ReSharper did say something about backing up my settings but Jayzus knows where I put them.

Here's a summary of the changes:

• Consolas font. Because I was told to. But at 11pt because 10pt seemed too small. Guess I'm getting old after all.
• Display fifteen items in the Recent Projects list. Who works on less than six projects?
• Solution Explorer, Server Explorer, and Properties Window docked along the left. I like them here because they are closer to the code I'm looking at. And when I debug, they are docked along the right so it's always obvious whether I'm debugging or not.
• Spacing and formatting. Some years ago, a good friend and a developer I respect highly suggested the spacing scheme I currently use and I love it. In general, there are spaces within parentheses, both for function calls and in expressions. Casts are the exception so that they stand out as casts. I find this makes code much, much easier to read as does most extra whitespace in generally.

So export your own settings to back them up and check them out if you're curious and/or brave. Note that the formatting changes are for C# because at the moment, it's all I code in.

Sunday, May 07, 2006

Couple of short miscellaneous items to balance the tome I wrote last time:

1. The Start Page in Visual Studio can be customised to show your own news feed rather than the default one. Go to Tools | Options | Environment | Startup. I'm also told you can use something like http://www.feedjumbler.com to collate a bunch of your feeds together into one which you can then use as the main feed for Visual Studio. I'm feeling “sign-up“ averse today so I haven't checked out Feed Jumbler
2. You can also set the number of recent items that appear on the start page. Tools | Options | Environment | General and change “items shown in recently used lists“. Note that this also changes the number of items in File | Recent Files and File | Recent Projects.
3. There appears to be no way of getting rid of the Getting Started and Headlines sections.
4. Have been playing with the beta of ReSharper 2.0 and love it. Type “throw new“ and it displays only available exceptions. Reference a class with no corresponding “using“ statement at the top and it is added for you. Type “using“ at the top and it displays the full hierarchy of namespaces available, not just the current level. And I've only been using it for a day. But it is uninstalling as we speak. Granted, my laptop is two years old and showing its age, but there is a very noticeable drop in performance of Visual Studio 2005. Plus I got some unhandled exceptions when working in a SQL database in Server Explorer. Tried to submit the error to help the developer folks out but that required me to sign up for something. See point 1. Regardless, when I upgrade my hardware and when they're out of beta, I'll gladly hand over $150 for it (pending a review of Code Rush).