Should I include VB macros in source control with my project? - visual-studio

For a C# project, I make use of several Visual Basic macros in Visual Studio. I was just considering that these would be of use to other developers that work on the C# project.
The macros so far include removing trailing whitespace on save, organizing using directives and removing unnecessary ones, and an override for Ctrl-M Ctrl-O that expands regions. Would it be reasonable for me to include this macro code with my C# project in Subversion?
I don't know if it's even possible for macros to be made available/work in Visual Studio just because you open a particular Solution file, and that might be too invasive since some of the macros override existing Visual Studio behavior.

These are more like "useful tools" rather than code that is part of your project. I would not put them in SVN as part of your C# project, but if you think they are useful enough to be used by other team members, you could set up another SVN project just for these types of tools. Then your other team members could use them at their desire.
I think you would have to save the macro code to a file, and then you could just check the file into SVN. Whenever you changed the macro code, you could just keep SVN up to date with the latest macro code.

Related

Code file templates in Visual Studio 2010

Xcode has a feature where each type of file has a template that is filled out when that type of file is created. By default, those files are located at /Developer/Library/Xcode/Templates/File Templates.
These files are used to give whatever default code you want, such as a common file header, even including things like the copyright year. I've gotten quite used to the functionality in Xcode, but I find myself missing it in Visual Studio. With VS I have to manually copy-paste the header and modify it myself for each file. Is there a way to get Visual Studio to automatically populate files (such as cpp's or .h's) with code?
EDIT: I'm trying to do this with C++.
Yes, you can use templates with macros etc in Visual Studio as well. MSDN has an article on it, and there are various blog posts on the topic too. I know they work for C# and VB - I expect C++ works in the same sort of way, but you'll need to check of course. (Apologies if this isn't the case.)
Unfortunately last time I looked it required expanding and then compressing zip files in a way that seemed a little unnecessary, but it should be doable.

What type of extension for VS (and how) to make, to generate C# or C++ code from some text [more so a model]?

I am new to Visual Studio Extensibility and want to make an addin/extension which shall do the following:
It should read all the files with a specific file extension (assume "*.ump").
It should process the text/code/whatever in the files.
It should create new Class/Code file with some code in it. [The code will be produced in step 2, just need to know how to do it?]
Yet, I have been racking my brains through extensibility, saw the single file generators .... and addins which go through ProjectItems and can detect the file extension,
BUT I HAVE NOT BEEN ABLE TO FIND a complete tutorial, guide or explanation as to how or what to do!!
Please help...
You don't want to read all files with a specific file extension in Visual C++ project nor standard Visual C# project. You may do that with hand-made MSBuild project (included in the solution).
In Visual C++ projects, there is a way to define custom tools. They are run as separate processes, so you can implement them in anything you want. Studio will ask you whether you want to define a tool (they are defined in special xml files; studio has dialog for editing them) when you add a file with extension unknown to it. In Visual C# projects, just manually write a MSBuild tasks and insert them into the project.
Do whatever you want. IIRC the generated files will have to be included in the project though. Well, for MSBuild, just tweak the project to your heart's desire, but in Visual C++ they have to.
You can combine MSBuild (csproj,vbproj) and VisualC++ projects in a single solution, so I recommend using separate.
If you ever find out you need to compile for different target where you can't use Visual Studio, you'll be glad that you have stand-alone tool you were just calling from Studio and not something that embeds in it.

Changing the F# tools Visual Studio 2010 uses

I rebuilt F# with few syntax additions. I was able to tell VS2010 to use them for F# Interactive and for building, but the code editor still claims I'm making errors (even though the project builds just fine).
Is it even possible to change this? If it is - how?
As far as I know, there is no way to change the IntelliSense service used by F# in Visual Studio. The Visual Studio component isn't a part of the open-source release and it has a reference to strongly-signed FSharp.Compiler.dll. I'm not sure if there is some way to trick .NET to load a different assembly instead (specifying bindingRedirect in app.config requires the same strong name). If you find some way, let me know :-) I'd like to use it with my modified version of F# too.
If you want to get some IntelliSense for your modified F#, you can use the F# MonoDevelop plugin. The plugin is open-source and you can change the F# version used in the Services/FSharpCompiler.fs file (see the source on GitHub).

Visual Studio 2010 - Add Reference Tabs will only give me projects. No Browse Allowed?

My problem seems pretty simple. I have a Solution with multiple projects and basically I am trying to do some mixing with C++, C# and CLI. My problem is that I need to add references from my c++ project. When the "Add Reference" dialog comes up, I only get tab for "Projects".
I know that usually you get multiple tabs for adding different reference types. What I am interested in is the "Browse" dialog. I need this to add a reference to a dll that is prebuilt. I am targeting .Net 4.0.
It seems like there is a project property that can be set to limit this but I'm not sure. MSDN seems to mention something along the lines that if you have multiple projects in a solution and they target different versions of the .Net framework, the list of possibilities may be limited.
In "How to: Add or Remove References in Visual Studio" MSDN mentions: "The number of tabs available at the top of the Add Reference dialog box can vary, depending on the type of project open and the resources it is using. C++ native projects contain only a Projects tab."
It doesn't really mention what these are specifically so maybe its just a broad subject. Anyways, I have stripped down the solution to only my C++ project and I can build successfully. However, I can only add References to other projects.
Apparently, setting the CLR option on the project is what opens up the list to include more options. I only wanted to enable it on one source file, but I guess Visual Studio will not add reference capabilities unless you turn it on for the whole project.
Therefore, my solution was to enable it for the whole project, add the reference, and then remove the option on the project. Basically a dirty trick but just in case people run into the same issue, that is what worked for me.
Erik

Visual Studio IDE from the perspective of a UNIX programmer

I've been programming in Linux/UNIX for several years now, but recently I needed to do some stuff in VS2008. I had difficulties with understanding how VS organizes work. Do you know any resources (free web pages preferred, but books also acceptable) which would show me a general picture and explain at least some details? Examples welcome, comparison with typical UNIX stack very welcome.
I don't need a language (C#/C++/VB/...) reference/guide; I've seen some of them and none of them seem to suggest how to work with VS efficiently.
You might be interested in introductions to MSBuild, the project format of Visual Studio. Whereas in UNIX you have a autoconfig script, and Makefiles, VS2008 allows most configuration through right clicks and menu options.
A second area of interest will likely be build configurations. Instead of re-running the configure script on different targets, or for different stacks, you specify targets with the configuration manager. Once you select a new configuration ("x86", or "Release", or custom ones like "Production"), VS churns for a while, as it updates the Intellisense of your new preprocessor definitions, for example, and Resource files. Your "Debug" configuration will likely define the macro "DEBUG", so you can use regions surrounded with #ifdef DEBUG, for example.
Visual Studio organizes common groups of source files into "Projects", which can be referenced by one or more "Solutions". Projects establish interdependency on one another, and external libraries. If you look at the structure of the projects in the Microsoft Enterprise Library, you will notice that there are several different Solution files (*.sln) which encompass different groups of common project files. You might have a different solution file, for example, if you want to reduce load/compile time, by not loading the unit test projects with every build.
So, analogies:
UNIX way:
# ./configure
# make
# nano Makefile
# make
VS2008 way:
# (Set up "Project Properties", Conditional Compilation Symbols, Build Paths, all from GUI application)
# (Click Build)
# (Change Configuration)
# (Click Build)
I don't have any links for you, but:
Visual Studio can open one and only one Solution at a time
A Solution may have zero (not very useful) or more Projects
Code (in whatever language) goes into projects
Projects can have any number of files and/or directories
Projects can reference files anywhere, not just within their own directory structure (though few do)
Visual Studio is a very flexible and powerful IDE. I think the best way to get the big picture is to build that big picture yourself in your own terms by using the heck out of it.
Build configurations and project properties are definitely two areas you will want to focus on.
You should explore the various options and configuration switches for generating assemblies and how they are managed in general. Learning the various build options and how assemblies are managed can save you headaches down the road.
The VS debugger is a thing of beauty and I recommend investing some time in exploring its capabilities. I recommend you familiarize yourself with:
Breakpoint management (especially the breakpoint window) and also conditional breakpoints
The Watch and Locals windows
Thread and Memory windows and tools
Immediate window (often overlooked and underrated if you ask me)
Finally, you should take a look at some tried and tested tools and plugins and get familiar with them. I would personally recommend ReSharper, Dependancy Walker, and .NET Reflector. ReSharper is an excellent productivity tool and Dependancy Walker and .NET Reflector are excellent analysis and debugging aids
Here's a couple of handy stackoverflow threads:
Do you have any recommended add-ons/plugins for Microsoft Visual Studio?
Favourite Visual Studio keyboard shortcuts
Have you considered installing cygwin and gcc? If you're looking to write a console app, it might just do the trick.

Resources