Chris Flaat's WebLog : VS tips

Command-line build (devenv /build, MSBuild, etc.)

cflaat — Tue, 24 Aug 2004 18:50:00 GMT

In the comments about a post I made a year ago about devenv /build (here), a person named Peter just a couple weeks ago made the following comment:

When we use IDE to build a project, we have the file(s) checked-out, and IDE will build the changes (checked-out files), will command build do so? I.e. do I need to check in my changes in order to build them? If so, then that's a big drawback for command build.

Thanks,
Peter

Comments on that old post are now closed (maybe because it's a year old?), so I'll answer here. Peter, I'm not sure I fully get your question, but in general we build whatever's on your machine, be it checked out or not. This is true whether it's devenv /build or MSBuild.

There were a few other complaints about devenv /build putting up UI. When this happens, it's a bug (sorry!). In Whidbey, we will provide MSBuild, which is competely separable from VS and runs without any GUI around (as with NMake, NAnt, etc.).

Chris

MSBuild talk at PDC

cflaat — Sat, 18 Oct 2003 01:24:00 GMT

Hi all -

So, as I mentioned in an earlier blog entry, Alex Kipman & Rajeev Goel are going to do a PDC presentation on MSBuild (the new build engine we’re including with Whidbey). If you’re going to the PDC, be sure to check it out. It’s Monday, Oct. 27^th from 4:45-6pm in one of the big rooms. I’ve seen one of the early versions of their presentation and it’s very cool. They cover many aspects of MSBuild, including how it integrates with VS, and will have lots of technical details and demos. If you’re interested in build issues, check it out!

-Chris

Introducing MSBuild

cflaat — Tue, 16 Sep 2003 22:34:00 GMT

Hi all -

More stuff has come online. See here for a little blurb about MSBuild, which is what we're calling our cool new build engine that will ship along with Whidbey.

-Chris

PDC 2003 tracks announced

cflaat — Tue, 16 Sep 2003 19:08:00 GMT

Greetings, all!

Microsoft has announced the broad outline of the material to be presented at the PDC 2003. See here for the list of tracks & presentations.

Under the “Languages and Tools” section you’ll see a cryptic reference to “a new unified build system”. This is one of the really cool things we’re working on for Whidbey. As details get publicized, I’ll keep you all updated. Until more gets announced, however, that’s all I can say. (I’m not, alas, an authorized PR representative of Microsoft!)

The PDC will contain a lot of exciting stuff this year. I probably won’t be able to go myself (due to some scheduling conficts) but plenty of people from our team will be there. There will not only be cool stuff from VS, but also some great stuff from Longhorn (the next version of Windows).

That’s all for now! -Chris

More on configurations

cflaat — Fri, 05 Sep 2003 19:49:00 GMT

Greetings, all! In my entry about devenv /build, a reader named Toby mentions the pain of maintaining multiple configurations when you have a lot of them that are identical except for one flag. He says:

In my work, I'll deal with several types of configurations: release, debug, profile build, unicode/mbcs, managed/unmanaged, xbox/pc, inline assembly/unoptimized C, etc. Some of these are truly unique configurations, requiring differing compiler options, etc. However, some are really just toggling a flag (unicode/mbcs for example). Each of these toggled flags requires twice the number of configurations. And when one of the configurations changes, all of the variants need to be changed.

I’m sorry that this is a less than pleasant experience, Toby. I don’t know of any way to do this any better than the workarounds you mentioned, at least for VS 2002 / 2003. What you really want is a way to define a solution configuration that sets a few variables and then passes those into project configurations that are otherwise shared.

I can say that we are doing some things in the next version of VS (known as Whidbey) that should make this significantly less painful, especially in the command-line build scenario, although you may have to do a little low-level project file tweaking. We’re announcing some Whidbey features related to this area at the PDC in late October, so interested people should stay tuned (and I’ll be commenting on these new Whidbey features here in my blog).

Toby also asks why this evolved the way it did. I’ve been working in the solution/project area for only about a year & a half now, so I don’t have lots of insight into the historical evolution of this feature. But I would guess that most users are not doing the multi-axis customization of builds that Toby is, so this scenario was never really optimized for. But being able to richly handle this kind of scenario, unconstrained by any particular assumptions of the IDE, is definitely the direction we are moving in for Whidbey & beyond.

That’s all for now! -Chris

Building from the command line: devenv /build

cflaat — Tue, 19 Aug 2003 19:30:00 GMT

Greetings, dear readers! Today I want to talk about using devenv.exe to build a solution or project from the command line (as opposed to interactively inside the IDE). For example, you can say “devenv /build debug myapp.sln” to do a debug build of myapp.sln. Now, I have to admit that if there was one feature I could deny any association with, it would be this one. There are many things about this feature that are harder to understand and use than they should be. (In my defense I can say that this feature took its current form before I took over this area!) Rest assured, however, that we’re working to make some improvements in this space for Whidbey.

A number of users don’t even know this feature exists. But it’s very handy. If you want to build a solution or project from a build script then this lets you do it. Just type “devenv /?” from the command line to see what you can do. You can also see the documentation page for a full list of supported switches. I’m going to focus on the /build switch, but much of what I’m going to say also applies to /clean, /rebuild, and /deploy. And I’m using VS 2003 but most of these comments should also apply to VS 2002.

A key to understanding this feature is to understand the relationship between solution configurations & project configurations. See my blog entry from 8/14/03 for more on that.

The most basic operation with devenv /build is to build a whole solution configuration. This is pretty easy. If you have a solution called myapp.sln, and it has a configuration called “Debug” (which it normally would by default), then you can build it by typing “devenv /build debug myapp.sln”. This should give you the same result as if you opened up the IDE, picked that solution configuration, and did Build.Build Solution. (Note that you can only build one solution, and one solution configuration, at a time. If you need to build more than one, use a batch file to wrap your calls to devenv.exe.)

Another thing you can do is operate on one project at a time. If you have myapp.sln that contains proj1.vcproj and proj2.vcproj, you might only want to build one project at a time, without having to define a separate solution configuration. If you want to do this, understand that you still have to specify a solution configuration to give the build proper context. This is because some things, like project-to-project references, need a solution configuration context in which to be resolved properly. Therefore the syntax to build just proj1.vcproj in the solution’s debug configuration would be:

devenv /build debug /project proj1 myapp.sln

This basically says: “Build the debug configuration of myapp.sln, and only include the project proj1 in the build.”

When using the /project switch to specify a specific project to build, you can only specify one project at a time. If you pass the /project switch multiple times, the last one wins & the prior /project switches are ignored. If you want to build a certain set of more than one project, you should define a separate solution configuration.

Another thing you can do when building just one project is specify a particular project configuration to be built. Let’s say I wanted to build just proj1.vcproj again, but this time with the release configuration – and just for fun, using the debug configuration of the solution! I can do it like this:

devenv /build debug /project proj1 /projectconfig “release|.net” myapp.sln

The switch we’ve added is /projectconfig, followed by the value of “release|.net”. Why the funny syntax with “|” instead of just “release”? The trick here is that the configuration of a project includes not only things like debug/release, but also the platform you’re targeting. Ordinarily, VB & C# project target the platform “.NET” and VC++ targets the platform “Win32” (even for managed C++, which is confusing). But if you buy, say, a version of VC++ that targets Win64, that’s another platform choice. So, just remember than when using the /projectconfig switch you need to add “|” followed by the platform the project targets (which you can see in the Configuration Manager dialog under Build.Configuration Manager).

We hope to make many aspects of “devenv /build” a little easier to use in the next major release, but hopefully this information will make this feature less mystifying for the next time you want to use it.

That’s all for now! -Chris

Solution configurations & project configurations

cflaat — Thu, 14 Aug 2003 21:46:00 GMT

Greetings, dear readers! Today I want to talk about solution configurations and project configurations. These are important concepts that are essential to understand if you’re trying to do complex coordination of builds using VS, esp. if you're using the DTE or devenv /build at the command line. However, this is a tricky subject which even a lot of people within the Developer Division don’t fully understand. Also be sure to see the documentation page for project & solution configurations

Let’s start with projects. Projects can have an arbitrary set of configurations. Think of a configuration as a knob that tells Visual Studio how to build a project. The classic configurations are “Debug” and “Release”. For most users, there is no need to go beyond these. However, you might want to define your own project configuration if you want additional ways to build your project (say, with additional diagnostics built in) that don’t exactly map to what you want in a debug build or in your final release build.

You can create (or delete) project configurations in a dialog called the Configuration Manager. You can reach this via Build.Configuration Manager menu item. To add a new project configuration, find row for the project and find the “Configuration” column. Click on the dropdown and click on “<New…>” (this dialog will never win any usability awards). This lets you create a new project configuration. You specify three pieces of information. First, the name. Second, you can optionally specify another configuration to copy settings from (for example, if you’re making a configuration that’s just like your Debug configuration but only differs in a few settings, pick Debug to copy from). Third, you can create a solution configuration that corresponds to it (more about that later).

Understand that a project configuration is a parallel bucket of settings. If you create a new project configuration that copies from the Debug project configuration, you are doing a copy, but any changes you make later to the Debug project configuration won’t be reflected in your copy. (The same principle applies to solution configurations.)

Now, what’s a solution configuration? Think of a solution configuration as a bucket of arbitrary project configurations. Solution configurations don’t have to have the same name as project configurations. A solution configuration is essentially a list of all your projects where you pick which projects should be included and which configurations should be built.

Let’s try an example. Create a new C# Windows Application project. Now click on Build.Configuration Manager again to return to the Configuration Manager dialog. What you are looking at is the list of projects and configurations for the solution’s “Debug” configuration. There is only one project in the list. The configuration for this project that we’re building is “Debug”, and the platform is “.NET”. The “Build” checkbox is checked.

If you uncheck the “Build” checkbox, it means that the “Debug” solution configuration shouldn’t build your C# winapp project. So when you do Build.Build Solution, nothing will be built. This is useless for a single-project solution, but can be useful if you have a lot of projects and there are scenarios where you only want to build a few. In that case you can create a new solution configuration to do this.

How do you create a new solution configuration? At the top of the Configuration Manager dialog there’s a dropdown with a list of solution configurations. Click this dropdown and pick “<New…>”. Then you can create a new solution configuration. It’s just like creating a new project configuration except that instead of being asked if you want to create a new solution configuration, you’re now asked if you want to create new project configurations to mirror the new solution configuration. (To get rid of either a solution or project configuration, click on <Edit…> in the appropriate dropdown.)

Let’s go back to the Configuration Manager dialog for the C# winapp we created. We’ve discussed the “Build” checkbox, but what about the Configuration and Platform columns? These are very important. The two of these put together make a true project configuration. For example, if you have Debug and .NET selected, your project configuration is “Debug|.NET”. This is a very important point. When you reference a project configuration via the DTE or via the command line (devenv /build), you need to refer to project configurations using the combined form. Note that the platform can be different, e.g. in VC++ if you are targeting Win64. You can then have Debug|Win32 and Debug|Win64, and these represent totally different project configurations.

If you’re back at the Configuration Manager dialog with our little C# app, you should see the “Debug” solution configuration selected in the dropdown at the top. If I go down to my project and go to the “Configuration” row, the dropdown says “Debug”. Just for fun, change it to “Release”. If you hit OK, then every time you build the “Debug” solution configuration, you’ll be building the “Release” configuration of your project! This is kind of a silly example, but a practical application would be if you want to enable a special diagnostic build (e.g. heavy assertions) in one of your projects but not others. For a given solution configuration, you can pick arbitrary configurations for your projects.

In different parts of the VS IDE, you will sometimes interact with solution configurations and sometimes with project configurations. On the main IDE toolbar, there’s a dropdown that controls your active solution configuration. This is what solution configuration gets build if you do Build.Build Solution.

Project configurations come into play when editing project settings. For example, if you right-click on a project in the solution explorer & bring up the project’s properties (or if you just pick Project.Properties in the main menu) you’ll see a property sheet with the project configuration settings (expressed via its two halves, the basic configuration plus the platform). Once again, I want to remind you that when referring to a project configuration via DTE or devenv /build, you need to refer to the whole thing, e.g. “Debug|.NET” or “Release|Win32”.

One other note. You might be wondering if you can have a solution configuration with multiple instances of the same project. You cannot. However, you can approximate this using the Batch Build dialog (Build.Batch Build in the main menu), which I might cover in a future blog entry.

That’s all for now! -Chris

Sneak peek at Whidbey

cflaat — Wed, 30 Jul 2003 19:02:00 GMT

There's a news report about what MSFT disclosed at the VS Live! event. See the link for info about some of the cool things we're doing in Whidbey (the next major release of VS) and Orcas (the release after that). Whidbey is what most of the VS teams are spending most of their time on.

Now, some of the really cool things we're doing in Whidbey are still not disclosed, but probably will be in the fall. When they are, rest assured that I'll keep you all in the loop!

Later! -Chris

New VSIP program rollout

cflaat — Tue, 29 Jul 2003 20:39:00 GMT

There's now free registration at the VSIP site to become a VSIP ("Visual Studio Industy Partner"), which is the program whereby you can write a low-level package that integrates more deeply into Visual Studio than is possible as an add-in (or macro). The VSIP program is great for 3rd party companies that want to sell add-ons for Visual Studio. But anyone can participate, including hobbyists who just want to play around or add that one special feature they think would be handy. -Chris

Watson addendum

cflaat — Thu, 24 Jul 2003 23:18:00 GMT

A reader named Martin makes a good point made about my earlier weblog entry about Watson crashes; he says we could offer a way to let users provide more information when a bug is difficult to reproduce. Actually, we already do this in cases where we're having difficulty making progress, I just forgot to mention that. Thanks for bringing this up Martin. -Chris

Watson's revenge

cflaat — Thu, 24 Jul 2003 19:23:00 GMT

My dear readers, I have a terrible admission to make. But it's time to come clean with you. The fact is, of our hundreds of thousands of users, a small number encounter crashing bugs in Visual Studio. They are working happily along, and *boom* some terrible crash will occur. Then, a much-dreaded dialog will come up, saying:

“Microsoft Development Environment has encountered a problem and needs to close. We are sorry for the inconvenience.”

And then a little farther down it says…

“Please tell Microsoft about this problem.

We have created an error report that you can send to help us improve Microsoft Development Environment. We will treat this report as confidential and anonymous.

To see what data this error report contains, click here.”

Then you see three buttons: Debug, Send Error Report, and Don’t Send.

[It occurs to me that the lack of the word “The” in front of “Microsoft Development Environment” above makes it look like English is our second language. I’ll have to bug somebody about that…]

Obviously, in a perfect world users would never see this dialog. It means that our users had VS crash, possibly losing data. During product development we treat any bug that could make VS crash or otherwise lose data as extremely serious, and few such bugs make it into the shipping product. But it does, alas, happen.

So, what does this dialog do, and what does it all mean? We call this the “Watson” dialog (not to be confused with the Dr. Watson tool, which is related but different). The dialog exists so that when a user hits a crash, if they choose to hit the “Send Error Report” button then a condensed stack dump, which we call a minidump, gets sent to a server at Microsoft. If you’re curious or paranoid, click where it says “click here” and you can see exactly what’s going to be sent to our server.

Once that happens, you can hopefully go on with your work. On our side, however, the work is just beginning. We have people who go through the reported crash dumps and then open bugs in the main product bug databases so that our developers can look at the minidumps and try to figure out why the product crashed. This is an extremely unpleasant job, because the information in the minidump is so scant, and sometimes we can’t piece together the cause of the crash. Often, however, we can figure out what went from the callstack and make a fix. If a lot of people are hitting a crash in an already-shipped product then we consider rolling the fix into a service pack. If the report is against a version under development (e.g. an alpha or beta release), or if a very tiny number of people are hitting a crash in an already-shipped versoin, we generally roll the fix into the version under development.

There is, of course, a certain amount of “cosmic justice” in making VS developers suffer through the investigation of these Watson reports, since the pain of having the product crash from under you is much worse. And it’s a great motivation to code carefully so as to avoid code paths that could lead to crashes. (Which we do already through many mechanisms, but I figure every extra drop of motivation is a good thing.)

If you are ever unfortunate enough to see this dialog, please accept my apologies in advance. But if it does every happen, I hope you now understand what it means and I hope you will hit the “Send Error Report” button so that we at Microsoft can get your crash report and investigate it.

That’s all for now! -Chris

Don't take code (or solutions or projects) from strangers

cflaat — Wed, 16 Jul 2003 02:27:00 GMT

Greetings, my dear readers. I wanted to offer some suggestions about how VS users can safely handle code obtained from other sources. A combination of common sense and careful reading of the VS documentation would lead you to the same conclusions I’m laying out here, but I thought it might be helpful to summarize these tips in one place.

Now, most of you hopefully know that if you get a program from someone else via e-mail or on some other medium, it is extremely unwise to actually run that program unless you really understand what it is. If it turns out to be a malicious program, then any manner of terrible things might happen: you might lose all your data, your data might be sent to someone else, virus-carrying e-mails might get sent to your friends & associates, etc. And nasty programs can be transmitted via other files besides .exe’s: batch files, word processing documents, spreadsheets, etc.

What about Visual Studio solutions and projects? My guidance to you is simple: Do not open, build, or run solutions or projects from untrusted sources. They could be malicious and could be every bit as dangerous as running a malicious executable. Treat them with the same care you’d give an untrusted .exe. I’ll discuss ways to mitigate this such that you can try to work with code from an untrusted solution or project without getting burned, but understand that this course of action is inherently risky. If in doubt, don’t even open a solution or project from an untrusted source, and for heaven’s sake don’t build or run it.

Now, perhaps I’ve scared some of my dear readers with the above statements. But none of this should be too surprising if you think about what a solution or project is. A solution or project expresses how to build a program (which itself could be malicious). So you not only have a potentially evil program, you have a bunch of other associated operations that help to design & build that program, which themselves could be evil. Note that at an abstract level, it’s not really any different than if you downloaded a .cpp file and a makefile – if the makefile erases your hard drive instead of compiling the code, it doesn’t really mean NMake.exe is inherently bad; it means you were foolish to invoke a makefile from an untrusted source. Makefiles are inherently powerful; so is VS.

If you do want to be able to grab code from other sources, then read on and I’ll offer some tips so that you can better understand how to manage the inherent risks of doing so.

One note about VS 2002 and VS 2003. If you’re still using VS 2002, consider upgrading to VS 2003. This isn’t some sales pitch I’m making in order to boost the stock price. VS 2003 has a lot of small improvements, including security-related ones, that make it a valuable upgrade from VS 2002. However, the advice I’m giving here still generally applies if you use VS 2002.

Now, I had originally wanted to describe this stuff starting with the simple cases and then working up to the complex ones. However, the most complex case, the issues with opening a solution or project, are the first thing one is likely to run into, so I’m going to tackle that first.

Why is it potentially dangerous to simply open an untrusted VS solution? Well, if you’ve read the VS documentation carefully (e.g. this page), you might have noted some ominous warnings about how opening up the VS.NET forms designer can run code in your project, and therefore you need to ensure that the code is trustworthy before opening it in the designer. I’ll not go into the deep, dark details of this (after all, I don’t want to make it any easier for people to do harmful things), but suffice it to say that a project can be constructed such that merely opening up a form can cause (potentially evil) code in the project to be executed.

In VS 2002 this could be very dangerous because if you opened up a solution we would also look at your .suo file, which has a list of what files to open up when the solution is opened. So…if you created an evil solution that would run evil code when the designer is used on a form, and your .suo indicated that the form should be opened when the solution loads, simply opening up the solution file would cause the evil code to be run. In VS 2003 this is mitigated to some extent; in VS 2003 we don’t automatically open any files listed in the .suo unless the .suo was created on your machine. Therefore if you’re using VS 2002 and you decide to ignore my advice about opening untrusted solutions/projects (please don’t!), you would definitely want to delete anyone else’s .suo file before proceeding.

However, even with that change in VS 2003, opening up an untrusted solution is still dangerous. If you open the forms designer on an evil file, you’re toast. Plus, if you then build or run the solution, you’re potentially toast as well, as we’ll discuss shortly. This is why I’m giving the general recommendation to avoid opening untrusted solutions / projects in VS -- it’s just so easy to get into trouble, even if you’ve managed to safely open it.

Let’s talk about running & building an untrusted solution or project. Taking an untrusted solution/project and running it (e.g. by hitting F5) is extremely foolish. It’s basically the same thing as taking an untrusted .exe and running it. True, you can see the source code, but it’s not hard to do evil things with innocent-looking source code. Even stepping into the program with the debugger (e.g. hitting F11) may not be safe, since obscure initialization code might get run before the entrypoint that you’ll be stepping into.

Building an untrusted solution or project is likewise hazardous. It’s easy to insert nastiness into the build process (running an .exe in a custom build step is one way, and there are many others).

The best thing to do is only take code from sources that you can reasonably trust, like from resources inside your organization, people you personally know, from companies or authors that you trust, etc.

If you wish to use code from a source you do not fully trust, the best thing to do is take little snippets that do exactly what you want and which you can fully understand. For example, if you want to learn about drawing graphics with DirectX, create your own program and try to find snippets to do exactly what you want (e.g. drawing a circle on the screen). This is much safer than grabbing some huge sample program from a random place on the web where you can’t be sure of who wrote it or whether they are trustworthy.

If you want to grab some big, complex project or solution from an untrusted place on the web, stop and assess your sanity. If you believe that you are on the correct side of the sanity line, you are an expert on the language & API’s the code is written with, and you understand that you are taking a huge and rather foolish risk, then here’s my advice as to how to defend against disaster:

1) Take only the code files (the .cpp files, .cs files, .vb files, etc.). Do not take the .sln, .suo, .*proj, etc. files. Likewise, do not take makefiles, NAnt files, batch files, etc. as these can also be malicious.

2) Open each code file in isolation and read every line. Do not open it in the VS forms designer. Instead, use the Open With feature of VS (detailed in one of my earlier blog entries) to view it with the VS source code editor or just use Notepad.

3) Inspect every line. If you see anything that either looks dangerous or which you don’t understand, don’t go any further until you figure out what it does and why. You are on your own, and responsible for the consequences of not fully understanding the code.

4) Create your own VS solution & project (don’t use the one that came with it).

5) Add the files that you’ve inspected & that you believe are safe to your newly created project.

6) Take a deep breath and do some soul searching as to whether you really want to go any further: at this point opening files in the designer or running the program will lead to disaster if you missed something in step #3.

One thing I also want to make clear is that most of these issues apply to any code and any development environment. If you obtain makefiles, batch files, perl scripts, awk scripts, etc. from an untrusted source, they are potentially dangerous if you run them.

I hope this information is useful, and I hope I’ve made it clear that untrusted solutions, projects, and code need to be handled with the utmost care. I’d love to hear any comments that readers have on this topic. If you have comments, please add a blog comment.

Bye for now! –Chris

[Please note: This weblog entry is provided "AS IS" with no warranties, and confers no rights. Opening and/or using solutions or projects from untrusted sources is inherently dangerous and the author, Chris Flaat , does not recommend it. If you attempt to open and/or use a solution or project from an untrusted source, then you do so at your own risk.]

Linked items and SCC integration

cflaat — Sat, 12 Jul 2003 02:26:00 GMT

A person named Blair commented on one of my prior entries about using linked files. They mention that the integration of a project's linked files with source code control has some limitations, esp. when you link to files outside the current project directory.

I looked into this issue a bit, and I can state that this claim is, well, uh, shall we say...not entirely inaccurate. :-) However, it's not quite as bleak as one might think. I talked with some people who understand this particular issue a lot better than me, and here’s a summary of what they told me.

In VS 2002 and VS 2003, when a project with linked items is added to source code control, VS goes through and calculates the closest common parent to all the files in the project, and that becomes the root of the project in VSS (we call it the “unified root”). If later you try and link a new file, AND it’s under the existing unified root, it will be added to SCC. (If it's not under the unified root, it will still be added as a linked file but won't be added to SCC.)

For example, let’s say you have a VB project in c:\My Visual Studio Projects\foo and you've added c:\boot.ini as a linked item. If you then add that project to SCC, your unified root will map to c:\. If you then add another file from somewhere under c:\ as a linked item then it should still get successfully added to SCC. (However, if you try to add a linked file from another drive, e.g. under d:\, you can add it as a linked file but it can’t be added to SCC. That’s just a limitation of the current SCC integration.) The most important thing to understand is that when you do the first “Add to Source Control” operation, your initial unified root is set up.

If for some reason you really need a linked item from another drive, you could work around this by adding to your solution a new project that lives on the other drive, add the linked item to that project, and then add your whole solution (e.g. with one project on c: and one project on the d: drive) to SCC.

Bottom line: Where possible, the best thing to do is figure out ahead of time what linked files (and other projects) you need, and add them to your project before adding the whole project to SCC. Obviously, you can’t always know that up front, but when possible this is the way to go.

If you already have a project under SCC and you really want to add an SCC-controlled linked item to it from somewhere outside your unified root, you could try to work around this by changing the unified root, but this is complex, risky (you could lose change history), and not really recommended unless you’re a really advanced VSS user.
A (somewhat lame) workaround is simply to avoid using SCC with linked files. Put the file under the same directory as your other files, and you’re done. If this is feasible, this is clearly the path of least resistance.

Personally, I use linked files only when I want to occasionally view a file that isn’t really “part of” my project, but still get syntax coloring, symbol browsing features, etc.
So, I hope this provides some useful information about how this stuff works, and suggests some ways to make linked files coexist better with source code control. If you want to read more about linked items, this MSDN page is a good place to start.

Have a good weekend! -Chris

Saving files with different encodings & line endings

cflaat — Fri, 11 Jul 2003 21:40:00 GMT

Now, this feature could be described as more of a text editor feature than a project feature, and it's not owned by my team, but it's relevant & useful enough that I think it's worth mentioning here.

With VS you can save a text file with an arbitrary language encoding (ANSI, Shift-JIS, Unicode, UTF-8, etc.) and arbitrary line endings (CR/LF, CR only, etc.).

If you're using VS 2003 (I think these steps are identical for VS 2002), then open up any scratch text file (e.g. .vb, .cs, .cpp, .txt, whatever). Then go to the File menu and pick Save <file> As (or hit alt-F followed by A) to bring up the Save As dialog.

As with some of the prior tips I've mentioned, the magic lies in the obscure little down-arrow at the right edge of the "Save" button. Click on this little down-arrow and click "Save with encoding". If you didn't change the filename you'll asked to confirm that you want to overwrite the current file -- just say "yes", assuming this isn't a critical file that you didn't want to churn; otherwise choose a different filename and you won't get that confirmation msgbox.

You will then reach the "Advanced Save Options" dialog. You can now tweak the save operation to change your encoding or your line endings.

Line endings are a simpler issue so let's start there. The dropdown lists four options. "Current Setting" means "leave your line endings alone". The other three are self-explanatory, giving you a choice between CR/LR, CR, and LR as your newline sequence. These are useful if you want to share out your files with someone on a Mac(TM) or Unix(TM) system.

Encoding is a thornier issue, and in the dropdown you will see a vast number of choices. The first thing I will say is that if you don't know what you're doing, don't change your encoding on important files because you could permanently lose data.

If you do know what you're doing, here you will find lots of useful encodings for your file. Lots of MBCS encodings, many Unicode variants (UTF-16, UTF-8, UTF-7, variants for big-endian, no signature, etc.), and lots of OEM and other encodings whose subtleties I don't claim to really understand. Changing your encoding lets you store international characters that you might not otherwise be able to store in your file, but be careful not to switch to an encoding that the tools & editors you want to use with the file can't understand. Also understand that if you have characters in an encoding like Unicode, you could potentially lose data if you save to another encoding which cannot express all the same characters. Be very careful because if you are randomly changing encodings you could lose data.

A fairly useful page on MSDN about language encoding issues is here. This page has several useful links at the bottom if you want to learn more.

That's all for now. -Chris

Chris Flaat's WebLog : VS tips

Command-line build (devenv /build, MSBuild, etc.)

MSBuild talk at PDC

Introducing MSBuild

PDC 2003 tracks announced

More on configurations

Building from the command line: devenv /build

Solution configurations & project configurations

Sneak peek at Whidbey

New VSIP program rollout

Watson addendum

Watson's revenge

More thoughts on handling untrusted solutions/projects

Don't take code (or solutions or projects) from strangers

Linked items and SCC integration

Saving files with different encodings & line endings