There aren’t many developers out there who aren’t at least curious about Microsoft’s upcoming new language, C#. Microsoft knows this. That’s why it has made the .NET Framework beta and its C# compiler publicly available via free download and as CD inserts in a variety of trade magazines. The Framework is nice, including all the requisites you’d need to begin writing code for the .NET platform. However, as with Sun’s Java Development Kit, basically all you get are a set of command-line utilities—no editors.
Sure, you can use Notepad or some other text editor to write your code, but where’s the fun in that? As anyone who has read my past articles here on Builder.com knows, I’m an admitted IDE addict. The only IDE available thus far capable of handling the new language is Visual Studio.NET, which is still in beta, and currently available from Microsoft only if you a) have an MSDN Library subscription or b) are willing to pay Microsoft a shipping fee to have it mail you a CD. Wouldn’t it be nice if we could use an existing IDE instead?
A “borrowed” editor
I was understandably interested when I read a section at the beginning of Tom Archer’s new book, Inside C# (2001, Microsoft Press, $39.99) explaining the steps he followed to adapt the Visual C++ 6 IDE for editing C# source code. He recommends the following:
- · Make Visual C++ recognize files with a .CS extension (C# source files) as valid source files by editing the registry, and changing the key: HKEY_CURRENT_USER\Software\Microsoft\DevStudio\6.0\Text Editor\Tabs/Language Settings\C/C++\FileExtensions from cpp;cxx;c;h;hxx;hpp;inl;tlh;tli;rc;rc2 to cpp;cxx;c;h;hxx;hpp;inl;tlh;tli;rc;rc2;cs by adding “;cs” to the end.
- · Tell Visual C++ what the C# reserved words are so that it can highlight them for you in the editor: Create a plain text file listing all the C# reserved words, one per line, and save it as usertype.dat in the same folder as msdev.exe (C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin if you used the default installation locations). This step isn’t as much work as it sounds like it would be. I created the required file from Microsoft’s C# language specification, and it appears in Listing A.
Archer’s customization is sufficient to enable you to write C# code using the Visual C++ editor. You don’t get intellisense, but you do get syntax highlighting, and interestingly enough, the editor’s class and member wizard bars will recognize the C# classes and members in your code, enabling you to jump to them in the editor window. But you’ll still have to run the C# compiler from the command line.
The compiling’s the thing
What good is an IDE that can’t compile the code you write? By taking advantage of Visual C++’s support for custom build rules, I discovered a way to fool it into compiling C# code from within the IDE. Basically, what we want is for the C++ compiler to skip all files in a project with a .CS extension and instead run the C# compiler on them. We do this by setting up the following custom build rule for the “main” source file (the one with the static main method defined) of the application:
csc /out:$(IntDir)\$(TargetName).exe $(InputDir)\*.cs
So what does that do?
The above command tells Visual C++ to process all C# source files, $(InputDir)\*.cs, through the C# command-line compiler (csc.exe). The /out: switch we pass to the C# compiler controls what the resulting executable’s name will be. Here, we want to use the name of the project, $(TargetName), as the executable’s name and have the resulting file placed in the workspace’s intermediate files folder, $(IntDir).
Using the /out: switch isn’t really necessary, unless you plan to use Visual C++’s Execute Program command to launch your program. This command expects the executable to have the same name as the project and be in the workspace’s intermediate directory. C# uses the first source file’s name for the executable by default, so you could omit the switch and your app would still compile, but Visual C++ might not be able to locate it when asked to launch it for you.
Hacking away again
To set up the custom build rule, assuming you’ve installed the .NET framework and performed Archer’s suggestions above, follow the steps listed below.
I’m sure you know this already, but just to make sure there’s no confusion: The .NET Framework is a beta product, and as such, should not be used for any production purposes. Also, while every attempt has been made to ensure that the procedure provided in this article is both functional and safe, there is still a potential for harm from following these steps.
- · Start Visual C++ and create a blank Win32 console application to hold the code for your application. Other application types would probably work equally well; you just need a container for your code.
- · Write the code for your application in the C++ editor, saving each file with a .CS extension.
- · Before compiling your source for the first time, choose the Settings option from the Project menu.
- · Select the application’s main source file in the project files tree. On the General tab, click the Always Use Custom Build Setup check box.
- · On the Custom Build tab, enter the following into the Commands text box, all on one line: csc /out:$(IntDir)\$(TargetName).exe $(InputDir)\*.cs. This is the custom build rule I introduced above.
- · In the Outputs text box, enter: $(IntDir). This is actually ignored for our purposes, but you are required to enter something here.
- · If the Project Settings window now looks like Figure A, you are in business and can click OK.
|The Project Settings window showing a custom build rule|
Congratulations: You now have a working C# IDE capable of editing, compiling, and testing C# applications. Of course, you still won’t have intellisense or any debugging support, but any compilation errors in your code will be reported in Visual C++’s Output window, as shown in Figure B. You’ll also have the traditional functionality of this window, such as clicking on an error message to be taken to the line that caused the error.
|Oops… that didn’t compile.|
One of the shortcomings of using this method is that the custom build settings have to be assigned to the main source file in each project individually. (You’ll have to perform steps 6, 7, and 8 for each C# project you create.) Another is that all source files in the project directory wind up being compiled. There may be a way around these limitations that I’m not aware of—a generic custom makefile perhaps. If you happen to know of one, please share it by e-mailing me. Of course, we’re only talking about a temporary solution to see you through until you can get your greedy mitts on the next version of Visual Studio, so you hopefully won’t have to endure it for that long. Until then, good luck and have fun.
Can’t wait to try C#?
Are you trying to learn C#? What suggestions do you have for fellow developers wanting to learn it? Send us an e-mail with your thoughts and suggestions or post a comment below.