How do I learn the Visual Studio way of thinking about software development?

September 24, 2008 1:45 PM

Visual Studio for the confused: I've inherited a C#/ASPX Net 1.1 application from what appears to have been some fairly low-skill software developers. The language, systems environment, and cleaning up the software itself aren't problems, but what the hell am I supposed to do with all this IDE stuff? I need learning resources.

My previous software development experience has been with fundamental tools: Makefiles, gcc, Ant, javac, and scripted build processes. I've used IDEs before, but entirely for the purposes of coding and analysis, not build processes and SCM. The situation I find myself in now requires I come up to speed on the Visual Studio 2003 build system, and I'm finding it makes absolutely no sense whatsoever due to my lack of grounding in graphical build tools. It's further complicated by the way the tool seems to be conceptually tied to a web server for the purpose of development.

There seems to be a tremendous amount of magic hidden in things like "solution files" and "project files" and zillions of little "properties" windows that own metadata about dependencies and the source tree, and it's all very confusing for someone coming from a more traditional and modular software tools environment. Reverse engineering this stuff is sapping a tremendous amount of my time and productivity, especially since it seems like the previous folks on the project made assumptions about the build environment that are no longer true.

So what should I be reading that will give me a background on this Microsoft-flavored build environment so that I can get to the work at hand? I want to get this code into Subversion and make it buildable by anyone who can check it out, but that is looking more and more like I'm going to have to rejigger what happens when the Build button is pushed to remove hardcoded UNC pathnames of servers that don't exist, an almost arbitrary scattering of build prerequisites, and dependencies on having a web server at hand just to produce object code and a MSI installer.

Right now I'm coming up against something that seems like an alien artifact from a world where the definition of what a codebase is and how you build it happens to completely differ from my own. It seems completely ass-backwards every time I look at it and adds a layer of complexity that I'm unaccustomed to in my tools. Overcoming that barrier is going to be key to my short term success. What should I be reading to learn best practices about Microsoft-flavored development tools and fundamentals of the Visual Studio way of thinking about a software "solution" in order to put this codebase on track to be properly maintained? Where I come from, a couple of hours with a text editor, a fresh build script, and svn ci would have given me build automation, SCM, and code drop portability. Instead I'm in a maze of twisty little properties pages, all alike, and eliminating my ignorance is an important first step.

Please note that I'm not asking about tool choice. I can make tool decisions on my own. I'm looking for ways to educate myself on how what I have works as is, so I can make intelligent decisions about how to restructure and retool the project for maintainability and save a lot of pain for the next person who has to tend to this application. I work with that next person, and want to be nice to them by giving them a software project, toolchain and development process that Just Works.

posted by majick to computers & internet (11 comments total)

i'm not sure if this is something you have control over, but most large c# projects i have worked on have been built using nant. i do not have a lot of experience with ant, but i imagine your existing knowledge should carry over.

you mention a couple of times that things are hidden in the solution and project files. if you have not already noticed these files are at their heart text files; you can view and edit them in your text editor of choice if you prefer.
posted by phil at 2:10 PM on September 24, 2008

If you're going to stick with VS, then I would create a new project, then add the actual source files to the new project. This should eliminate the references to network drives and such.

As far the web server dependency goes, Windows XP Pro includes a cut down version of IIS, so the dev machine should have a web server on it. You may have to install it from the XP install disc, but it's available.

VS 2005 and 2008 include a simple built-in web server for development, which makes things much, much simpler. If you can swing a copy of 2005 or 2008, I would recommend it.
posted by jedicus at 2:11 PM on September 24, 2008

Thanks for the tips, folks, but again, I'm very much not looking at making tool decisions right now. I'm looking to understand the existing, somewhat broken build system such that it can be redesigned. Unfortunately I face a big problem at this point: I don't know enough about VS to understand why the build tries to do some of the less obvious the things it does. After I can do that I'll pick tools or deal with OS component workarounds.

So the question still remains: how does one go about learning both the underlying concepts and implementation intricacies of Visual Studio's build system, so I can untangle and eventually restructure this thing?
posted by majick at 2:24 PM on September 24, 2008

I may be way off track, but maybe one of these will help?

Visual Studio debugger and tips (includes a "what about other's code" section):

VS .NET IDE Tips and Tricks

User's Guide to Visual Studio SDE
posted by misha at 2:56 PM on September 24, 2008

So, the key to understanding VS's build system is to think of it as a makefile generator, like cmake or qmake.

It takes a list of files, finds dependencies, and then runs a traditional make-like build based on file timestamps.

There are a few other things that will ease the pain - the project file is an XML file specifying all the files in the project. The solution is an XML file specifying all projects in the solution.

Older versions of visual studio used to have the ability to export a makefile for use with nmake. This has been removed. You can build from the command line using the project file and devenv.
posted by tfinniga at 3:59 PM on September 24, 2008

I'll try to describe a few basics, some of which you probably already know. I don't pretend to have deep knowledge about the VS build system, but I came to VS from a Un*xy background as well and overtime I've gotten used to its way of doing things. It's not nearly as flexible as Makefiles, ant, etc., but most of the time you can get it to do what you need if you can find a way to fit into its framework.

First off, a solution is just a collection of projects. A solution basically has no settings of its own; it's just a way to conveniently group projects so they all appear in the UI. When you build the solution, it just means it's going to build all the projects in the solution, so in that sense it's kind of like the high-level makefile that just calls make on a bunch of makefiles in subdirectories.

A project builds a single target (e.g., an EXE or DLL file). The project file contains the list of source files, plus 'references' and settings. The references are dependencies on other targets. A project can reference another project that's in of the same solution, in which case the referenced project will be built first if needed. A project can also reference other DLLs or EXEs or system libraries. Any referenced targets will will be copied into the project's 'bin' folder.

The linkage between VS and IIS for web projects is actually less magical than you think, but it's not obvious from VS's wizards how it's actually setting this stuff up (which is probably why your codebase ended up the way it is; the developers just blindly used wizards and followed tutorials without understanding what was going on underneath, which unfortunately seems to be what MS's documentation encourages for the sake of being "easy to use"). All a web project is really doing is building a DLL in a folder that IIS knows about. You can just as easily have it build the DLL somewhere else, and then set up a virtual directory in IIS. That's how the project I work on is set up -- all the projects are consolidated under one folder, and then IIS is pointed to the web app. This works just fine, including debugging and all that.

My suggestion for approaching this is to first start consolidating everything under a logical folder structure. Move the web app out of C:\Inetpub into a proper place. Find all the dependencies and move them into a logical structure. Often it's helpful to view the solution and project files to figure out where it's looking for this stuff, and sometimes you may find it easier to hand-editing them than figure out the UI. Once you've got everything consolidated, you can import the code into Subversion. There are SVN UIs that integrate into VS, or you can just use the command-line or TortoiseSVN (my recommendation, since I dislike integrated SCM).

Anyway, I hope this is somewhat helpful. I joined a project that basically had a single development and production environment (same machine), and did the initial legwork to make it possible for multiple contributors to develop on separate machines, basically just so I could do my development without constantly stepping on other people's toes, so I went through a bunch of what you need to do. Mostly I muddled through and built my understanding as I went.
posted by Emanuel at 5:57 PM on September 24, 2008

To second tfinniga, you can emulate what happens when you click "Build" in the IDE by using devenv with params at the command line. You can also use VSS [assuming that's what's being used for SCM] from the command line as well, so you could as a first step just wrap the build up in a batch file.

That right there may make you a bit more comfortable, and then you can take the next step of opening up those *.sln and *.vcproj files and checking out what's in them, changing paths and whatnot.

Once you've got the "check the code out from VSS" working, you can switch that over to "check the code out from svn", and eventually get the whole thing building from ant or the tool of your choice.

At my previous job, I had a type-go-and-walk-away ant-based build script that retrieved a source tree from VSS, compiled a half-dozen C++ apps through Visual Studio 2005, a java applet, some other gunk, then built an Inno Setup installer from it all. It itself evolved from a *.bat-based system driving MSVC2 and PVCS. Not rocket science, but I could probably give you a cut-down version of it for illustration purposes.

I probably even still have the *.bat version, if that would be helpful. It might take me a little while to divest either of them of any previous-employer-specifics, but I'm happy to share the skeletons if they're of use.
posted by chazlarson at 6:11 PM on September 24, 2008

There's also msbuild.exe, the command-line tool for building project and solution files.
posted by XMLicious at 7:14 PM on September 24, 2008

i know that you have said you were not interested in evaluating tools or installing iis yet but just wanted to point out a potential pitfall when using vs 2003. if your solutions contains web projects they will be referenced by url and if vs 2003 can not resolve the url these projects are excluded from the solution. in order to open a solution that contains web projects you will most likely need to install iis and create at least one virtual directory first. if you examine the solution in a text editor you will be able to see the url that is being used.

this issue has been addressed in both vs 2005 and vs 2008.
posted by phil at 6:24 AM on September 25, 2008

Thank you, folks, for what you've shared. I'd have loved to get even more depth, especially where I'm running into the more obtuse parts of this project that involve building Crystal rpt files and importing some Office integration shims, but you've already set me off in the right direction if not quite yet on anything like a path.

"[I]f your solutions contains web projects they will be referenced by url ... this issue has been addressed in both vs 2005 and vs 2008."

I'm definitely fighting this issue, since it's a completely insane way to go about things and assumes WAY too much about what I want to do during the edit/compile/package cycle. I actually have access to more recent Microsoft development tools, but nobody has managed to get this "solution" to build with them. It's possible that moving the project to a more modern VS will turn out to be a prerequisite for making any progress, and that's a shame.

"Once you've got the "check the code out from VSS" working..."

Alas, you assume far more competence on the part of the people who originated this code than is deserved. Version control seems to have been done by zipping up directories, and this is further complicated by the utterly insane "source artifacts on a web server" design of the tool.

"eventually get the whole thing building from ant or the tool of your choice."

To be honest, I'd prefer something that would be easily familiar to a VS user. I'm given to understand the VS IDE is a powerful tool, and I'd like to make use of it in a way that will be obvious to any given developer with a Microsoft tools background. It's less about imposing tools of my preference than it is about setting it all up in a way that's self-documenting, comprehensible, maintainable, and containable. I want anybody with a properly functioning VS toolchain to be able to do a checkout/change/build/checkin cycle.

"TortoiseSVN (my recommendation, since I dislike integrated SCM)"

I don't want to run off the rails on tool discussion, but what's so awful about the SCM integration? Am I going to run into VS limitations? Or is it more about VS itself assuming every SCM tool works like SourceSafe (*shudder*) regardless of the integration module? Or are we just saying that the TortoiseSVN use case is familiar because it's similar to svn(1)? AnkhSVN looks attractive, but if integrated SCM is a road towards headache I would love to know about it before I get too much farther along. At the end of all this I'm still going to be the change manager.
posted by majick at 10:11 AM on September 25, 2008

To answer about SCM integration, I think a lot of it is that I tend to develop remotely (accessing the repository through a VPN over a laggy Internet connection), and I've found all the VS SVN integration tools are painful to use this way. If you'll be developing on the same LAN as the SVN server, then this is less of an issue.

Some of the VS SVN integration plugins do try to act like SourceSafe, and I definitely would not recommend any of them (PushOK is an example). Other developers on my team use AnkhSVN and it seems to work well for them.

Something I forgot to mention in my earlier note: each project (and even individual source files in the project) can have a pre-build and post-build step. Those are handy if you need to do any non-VS steps as part of the build process.
posted by Emanuel at 4:23 PM on September 25, 2008