The Future of Reflector is Red Gate

In an interview with Lutz Roeder and James Moore entitled The Future of Reflector, we find out that development of Reflector is being taken over by Red Gate Software.  The promise is that Reflector will continue to be "available for free downloading".  Will source code still be available?  Not discussed in the brief transcript of the interview. 

It will be interesting to see what happens to such a widely-used tool.  How will the community of add-in writers react?  Will there be a hue and cry from the Open Source community at large?

I told you a thousand times "Unit test!"

Calculating PI to a billion digits

Recommended site.

Unit testing static classes

Cibrax describes a method to unit test static classes.  The example given applies to WCF, but it can be applied to anything that would otherwise be difficult to mock.

Unified SCC - a universal source control integration plugin

This plugin could be useful if you are looking to use Subversion (or CVS) as your source control management system.  It claims to handle Delphi as well as Visual Studio, with other development systems in the works.

Source Control in a .NET World

Scott Kuhl blogs about finding a source control system to replace SourceSafe and comes up with a surprising new contender.

Having Pun with C#

Some Monday morning fun.

The Mythical 5%

Bruce Eckel's commencement address at Neumont University in Salt Lake City.  The school is geared toward teaching Comp. Sci.  Some excerpts:

We are in a young business. Primitive, really -- we don't know much about what works, and we keep thinking we've found the silver bullet that solves all problems. As a result, we go through these multi-year boom and bust cycles as new ideas come in, take off, exceed their grasp, then run out of steam. But some ideas seem to have staying power. For example, a lot of the ideas in agile methodologies seem to be making some real impacts in productivity and quality. This is because they focus more on the issues of people working together and less on technologies.

People issues.  In software as well as life, People Issues rule.  To condense further...

A man I've learned much from, Gerald Weinberg, wrote his first couple of books on the technology of programming. Then he switched, and wrote or coauthored 50 more on the process of programming, and he is most famous for saying "no matter what they tell you, it's always a people problem."

A third way to look at this:

...there's one more very important maxim from Gerald Weinberg which doesn't really answer anything as much as gives you a way to understand what happens. He says: "Things are the way they are because they got that way ... one logical step at a time." It's the legendary frog in the saucepan. So from your fresh new perspective things might look ridiculous, but remember that each decision on the way was made by someone weighing the issues and making what seemed like the best choice at the time. This viewpoint doesn't solve the problem but it can make you more compassionate about the people who are stuck there.

Amen.

This is worth taking the time to read.

Icon Restore

This is a nifty thing for those of you who change resolutions from time to time (or have them changed for you without your permission, if you know you know what I mean).

Icon Restore is free and does just what it says it will do.  Note that if you move things around after saving your icon locations, you will have to remember to save your new position.

If you like your desktop the way you like it, this is for you.

Two, Two, Two Mints In One

My employer, Alogent Corporation, is developing an API to interface to an existing piece of code I'll call Deposit Server.  It normally runs as a Windows service, which I'll call DepositServer.exe.  The API (WebApi) is designed to be called via the web, so it runs under IIS within the aspnet_wp.exe process.  Each of these has its own Visual Studio solution file, each with numerous projects.

If you happen to be coding and debugging on both sides of the fence (the Windows service and the IIS process), you can use one Visual Studio instance to attach to both processes at once in order to trace between the web API and the Deposit Server as traffic flows back and forth. 

What I did was create a single solution, let's call it DualSolution, by merging the contents of the existing WebApi and DepositServer .sln files.  Rather than try to figure out which Project entries were common to both solutions, and there are quite a number, I just copied the entire contents of each .sln file into the new one, back to back. 

When you open the resulting solution in VS, you will get a bunch of notifications that 'project xxxx cannot be added because it already exists in the solution'.  You just click OK, and VS will take care of the cleanup when you save the solution the first time.

(At first I thought I needed to merge the contents of the Global sections and have only one Global, but VS appears to take care of that as well.  Just append one .sln file after the other, open up the result, and you're good to go.)

When you want to debug, attach to process DepositServer.exe, then turn right around and attach to aspnet_wp.exe.  Now, you can set breakpoints from end to end. 

Of course you can do something similar by having two copies of VS running, one with the WebApi solution, the other handling DepositServer.  But it seems to me there are two upsides of the combined solution method:

1. You save memory by having only one copy of VS running rather than two
2. You save memory by not having the projects common to both solutions open twice

Devenv.exe (the guts of the Visual Studio IDE) tends to get pretty hefty as you ask it to do things;  here are the Working Set sizes on my machine, as reported by Process Explorer.  Your mileage will vary, based on what's open in the solution, the add-ins you've got installed, moon phase, how VS feels at the moment, etc. 

Each of these measurements was taken with all projects collapsed, no source files open, no Start Page open.  I let things "settle" for a while, as I notice the WS size creeps up a bit for a few minutes after the solution is open for business in the IDE.  The solutions are (for the moment) VS2005.

Solution opened and its state	Working Set size (in KB)
Visual Studio with no solution open	57,016
DualSolution, after opening	400,256
DualSolution, after attaching to both processes	421,404
WebApi, after opening	196,384
WebApi, after attaching to aspnet_wp.exe	212,228
DepositServer, after opening	403,508
DepositServer, after attaching to DepositServer.exe	427,004

 

Memory to debug with combined solution:	421,404 kb
Memory to debug with two VS instances:	639,232 kb
Not having to swivel your head between two sets of breakpoints in two different windows:	priceless

Hurry! Act now!!

Repent!  The End is Near!

It has been announced that Virtual Server 2005 will no longer be supported after 2014.  Plan now to migrate your virtual images, before it's too late. 

 

You know your company's getting big when it announces that an already outmoded product will see its sunset seven years from now.

Sysinternals Suite - New and Improved Packaging!

All of the good stuff in one package.  This is a great idea for a newly-paved machine. 

Windows cannot open this file

This has been an annoyance for a long time.  When you open a file with an "unknown" extension, you get the dialog asking you if you want to search the Interweb to find an appropriate program.  Like the author of this post, I have never, ever found anything through this.  I automatically choose "Select the program from a list".

Now you can perform some registry hackery to bypass this dialog and always go to the "Select from a list" step.

Buy 1, Donate 1 Laptop for $399 - The One Laptop Per Child Project

A while back, I saw a 60 Minutes interview with Nicholas Negroponti about the One Laptop Per Child Project, and it was very interesting.  These things really are useful in an African village.  Kids, as kids do, were taking to them like ducks on a pond.  It's a cool box, too.

Now we have a chance to both satisfy our lust for curiosity about the technology and help a child.  Come November 12th, there is a two week program where you can buy one of these babies and have one donated.  Sign up here to be notified when it officially starts.

Rob Walling has blogged about it.

WCF Performance Comparisons

Ken Brubaker points to a summary by Clemens Vasters of a white paper comparing various existing distributed communication technologies with WCF.  The bottom line - WCF is

• %25 - %50 faster than ASMX
• %25 faster than .NET Remoting
• %100 faster - %25 slower than .NET Enterprise Services (DCOM)

Also in his summary, Clemens remarks (italics his):

For WSE 2.0/3.0 implementations, migrating them to WCF will obviously provide the most significant performance gains of almost 4x.

The performance differences alone make WCF a technology worth exploring.

Team Foundation Server Version Control

Jeff Levinson provides a brief overview of how you could set up and do change management for development using TFS.  The approach is a bit different than I've seen in the past.

Hello Kitty assault rifle.

'Nuff said.

Integrating TortiseSVN with Visual Studio.NET

Here's a nice CodeProject article on both using TortiseSVN (the primo Subversion client) and integrating it with Visual Studio.  It discusses Ankh, VisualSVN, and an add-in developed by Garry Bodsworth (described here).  There are some useful tips on Subversion in general, and some of the comments have interesting questions and answers as well.

Beginning the WCF Journey

I'm going to dip my foot into WCF.  That's more than a toe but less than a headlong dive.  Of the four books listed in our library, I have found two.  Here are some quotes from the intros:

...you might instinctively treat WCF as just another API.  Resist this temptation... WCF is not just a wrapper around existing functionality or just another whiz-bang API.  WCF is the evidence that a tectonic shift has occurred in distributed software development.

Justin Smith, Inside Windows Communication Foundation

Tectonic shift!?  Wow!  Equally as eye-opening is this one:

To me, WCF is simply the next development platform, which to a large extent subsumes raw .NET programming. 

Juval Lowy, Programming WCF Services

This could be fun...

F# About to go Mainstream

I've been noodling around with F# for a while, partly to get used to the upcoming Functional Programming features of C# 3.0, partly to expand the way I approach programming problems.  Now, Somasegar has announced that Microsoft will be making F# a first class language, along with C#, VB.NET, etc.  This is very  good news, not only for devotees of ML-type languages, but also for FP in general.  When something is readily available in Visual Studio, there's more of a likelihood that someone will give it a try*. 

And while it's true that other ML implementations for .NET have been around for a while, such as Nemerle, SML, CAML, OCaml and Haskell, the polish that Microsoft will put on F# will make it much easier to use. 

Also, unlike some of the above examples, F# is under active development by Microsoft Research in the UK.  Don Syme is the leader of the team.  F# can be either compiled or scripted like Python, but it has ML's type inference and is type-safe.  It generally performs as well as (or better than!) compiled C# code.  For an intro and overview of features, check out the project's main page.

 

 

 

 

 

 

* Except for J#.  Don't ever try J#.

REMs don't sleep

Let's say you have a .BAT file with a command like

c:\bin\dcc32.exe   [parms to compile a Delphi program]

It will return an %errorlevel% of greater than zero if the program does not compile, zero if it does.

Since I was testing this by double-clicking, I put a PAUSE statement right after it to see the output of the compile step. 

c:\bin\dcc32.exe   [parms to compile a Delphi program]
pause

Once the whole build project started working, I left the PAUSE in but REM'ed it out so I could remember what I had done in case I needed to go back and debug later.

c:\bin\dcc32.exe   [parms to compile a Delphi program]
rem pause

It turns out that REM is an "active" statement in a .BAT file and sets %errorlevel% to zero!  When the compile line really did fail, the error was being masked by the REM right after it, so the MSBuild project kept going as if nothing was wrong.  Once the REM line was removed, the MSBuild project failed as it should.