This is just a quick link dump for anyone looking to use Team System’s source control with Visual Studio 2003.

I know that for our office, we’ll be supporting a number of VS2003/.NET 1.1 apps for quite a while, but we’d like to migrate all our source control to Team Foundation Server.

Vertigo Software has a good blog post about collecting all the parts and pieces and getting it working. The basic steps are:

1) Download the MSSCCI provider for Team System
2) Run a registry hack to get it to work

If you need to access multiple source control systems, then you should check out Soenke Schau’s Sourcecode Control Switcher app

All the details are over at Vertigo’s site.

Since hearing about Team System, we’ve been really interested to see how it can
work for us. While I don’t think we’re the exact target market (we only have 5
developers right now), we are keenly interested in the project managment aspects
of Team System – and Team Foundation Server is the core of all
that.

Being small means a number of things – one of which is that money
does not grow on trees. So, for our investigation, I’m setting up Team
Foundation Server using an only machine – 1Ghz with with 1GB of RAM. Since it’s
just me playing around, I think it should be fine.

I had tried to install this a Beta 3, but it failed miserably. The final version was released on the 20th, so I thought I’d take another swing at it. This time, the install went smoothly, and it’s up and running.

I will say that with power comes complexity. Once I wrap my head around all the roles and permissions, I think this will really rock.

At this point I’ve created a project, added some existing code into the source control, and just begun messing with Work Items. Still working out how to add users to the correct roles so that I can assign them work items, but I’ll get that sorted out soon enough.

The only beef I have at this point is that the project portals are not quite FireFox friendly.

Look for more Team System posts in the coming weeks as we start up a project that will run through it end-to-end.

I ran into a little trouble getting machines on my LAN to talk to the SQLExpress instance on my workstation, and thought I’d share the answer.

Very simply, all that complaining people did about how Microsoft ships server software in insecure configurations has had an effect. SQLExpress installs in such a way that the only enabled protocol is “Shared Memory” – which basically means localhost access only.

You can change this by opening the SQL Configuration Manager, and enabling TCP/IP and Named Pipes, and then re-starting the service. Then the other client applications can connect.

Made if back from Palm Springs just in time for a big old Front Range
snow storm. Right now its dumping in Fort Collins. Other bloggers have
already posted great information from the second day, so I’ll not
re-hash that – just link over there – James Fee, Rob Elkin, Cory Eicher.

My Additions:

First – a big kudos goes out to Brian Goldin and everyone else at ESRI who made this conference possible. In 10 years of attending conferences, this was by far the most useful conference.

Next – What can you say about the .NET ADF! Big big props to Art Haddad and
his team for making all our lives easier (when it’s released). We’re
already scheming up projects where we can use the ADF. Who says ESRI is
not raising the bar? For those not in the beta program, and who did not
attend, just wait! Web mapping elements are no-longer second class
citizens grafted into otherwise industry standard web-sites. Expect
seamless integration of mapping into any .NET 2.0 web site when this
rolls out.

Ideas for next time:

Software Enginnering Practices
As
someone noted in the closing session -  some sessions where ESRI talks
about their best practices re: software engineering process. Many GIS
developers do not come from a Computer Science background, and may not
work in shops where source control is taken for granted, and having
good unit tests is as important as having good code.

Real-World Applications
Sessions
which show real-world applications – co-presented by ESRI and the
developers would be very cool. This would inject the dirty reality in
which all problems can not be solved at the coarse-grained level.

Fine-Grained Love
And
- as echoed by many attendees – we love our fine-grained objects. So
sessions on that would also be great. Just to kick a topic out there -
“Best Practices for working with IGeometry”. This would be particularly
good because there are so many ways to interact with the low-level
geometry objects, and some are much faster than others (geometry bags
vs iterating over a collection). Add into that the “zen” of dealing
with precision differences between the map frame and a feature class,
and how that effects operations, and you’d have a weighty 75 minutes of
fine-grained love.

Back to reality and some non-ADF ArcGIS Server work.

Is it just me, or is it usual for Visual Studio 2005 to grab 700+ Mb after a couple of hours? This just seems pretty extreme. A leak perhaps?

I’m working on a winforms project that has about 10 user controls in it, but other than that it’s a very light weight application. Interestingly I did not see this same level of memory use when I was running the “Professional” edition – only once I switched up to “Team” for Developers. This is a drag because at this point the only “Team” thing I’m using is the testing. Curiously I thought this was in all versions but when I opened the solution on Professional, it could not open the test project.

At this point, I need to restart VS every 2 hours or so otherwise things just grind to a halt. What seems to be worse is that the amount paged get’s crazy – like 1.8 Gb!

These are screen caps after running for about 40 minutes… 486Mb for devenv.exe

and a page file at 1.08 Gb!

This is a new AMD Athlon 64 with 1Gb or RAM, and it flies most of the
time, but once I get VS 2005 open, things start to bog down hard. Anyone
else having this problem? Know of any tweaks?

Just a quick note to anyone
looking to get Subversion
(open-source version control system) up and running quickly.
 

The simplest,
get-it-running-now guide is actually in the TortiseSVN
help. There is lots of info in the actual Subversion
manual, but it’s more oriented to a subversion administrator and describes
installing subversion as…

The easiest way to get Subversion is to download a binary package
built for your operating system. Subversion’s website
(http://subversion.tigris.org) often has these packages available for download,
posted by volunteers.

That’s it. While factually correct, it’s not
particularly helpful if you have never set it up before. Once I found the
description in the TortiseSVN help, it’s really quite simple:

Step 1:
Install Apache Webserver (msi windows installer)

Step 2: Install
Subversion (windows installer)

Step 3: Open beer.

Step 4: Minor
config file meddling (help doc shows you what to do line by line)

Step 5:
Connect to the repository with your client of choice (TortiseSVN is a good
start)

Step 6: Toast yourself for a job well done.

Really, quite
easy – and thus there is no excuse for not using a source control system!

When I started writing software, like many other GIS developers, I was working
in a vacuum. I was the only VB developer in our shop, and I knew few other
developers. If I had a problem, I had to hope I could find a solution in a book,
or just solve it myself. Narry a mentor to be found.

Times have changed,
and the internet now provides a wealth of “How-To” type information for
developers. What’s still difficult to find are discussions which review the
“pros & cons” of a set of options – kind of “best practices” tempered by
reality. These are the sort of discussion that you would have with a mentor, and
from which you take away more than simply a solution – you gain knowledge.
Happily, I find that there are some blogs that can fill this role.

Just
this afternoon, I ran across a bunch of posts which exemplified this. I found
some serious discussions about some topics I’d been working with this last week
- Object Relational Mapping in .NET, and the choice between using dynamic SQL,
or Stored Procedures in a data access layer.

Ward Beeker’s blog on Code
Generation has a post
linking to a post
by Clemens Vasters (of dasBlog, and now Microsoft). Having spent the week
working in relative isolation looking at O/RM options, and finding most of them either overly complex or unable to map 1-to-M tables into contained collections in a
parent class, it was nice to see that other much more distinguished developers are also somewhat skeptical of the promise or O/RM. Anyhow,
both the post and the comments were very enlightening.

Once I had
decided on how to actually generate my classes from the data model (I chose to
use RapTier because it uses a very light weight model, which does not rely on
other code – unlike NHibernate or the MS Ent Data Access block), I still had to
decide if I should use stored procedures or dynamic SQL to communicate with the database.
Again – I found a bunch of postings on both sides of the issue.

• CodingHorror
  (Dynamic SQL),
• SimpleTalk
  (Stored Proc),
• Frans
  Bourma (Dynamic SQL).

What’s really cool is that in reading the
posts, I got insights that only come from people who have tried a lot of options, and have
summarized their results. From reading these, I think I’m going to go with the
Dynamic SQL. I’m doing this for the simple reason that if there is a need to
change the model, there is only one code change to make.

It is my hope
that I can provide similar help and insights on GIS development to the people
who read my postings on ArcDeveloper.net or this blog.