Is there any way I could save my block of code in Visual Studio 2010 and reuse it in my future web applications without having to "Add existing files"? Is there a feature in VS2010 that lets you globally store these blocks of code?
Thanks!
Oded pretty much covered it but I'll just reiterate here. There are three main ways you can do this depending on how much code you want to store.
For a little code just copy the code to your Toolbox:
Link
For a little code to very large blocks of code (with some intelligence for putting in values) you can use code snippets:
http://blogs.msdn.com/b/zainnab/archive/tags/tips+and+tricks/snippet/
And for lots of custom files, resources, etc... that essentially make up a new project you should use project templates:
Link
Visual Studio has a feature called code snippets, which will allow you to do exactly that.
If you want a more advanced use - for whole files, sets of files and even whole projects, use templates.
Related
When programming a big project, you often need the same pieces of code in different pages. calling methods, returning references, ...
Now, I always need to open a page, and copy paste parts from that. but I'm getting tired of that. There should be a better way to list very often used code. I've read about snippets but they seem a lot of work. How do you manage that?
Snippets are not a lot of work if you use one of the handy snippet-easing extensions to Visual Studio. I happen to like this one http://visualstudiogallery.msdn.microsoft.com/B08B0375-139E-41D7-AF9B-FAEE50F68392 by Matt Manela. Once it's installed, you can right-click a block of code and make it into a snippet. You can also set up replacements just like when you do an if or for block with the built-in snippets.
In most .NET project I can use folder to organise the code files. In C++, I can't, but filters end up playing the same role. However, in F# with Visual Studio 2010, I can't. Every code file is shown directly in the project dir. Why is this feature not available?
And what is the optimal strategy for organizing a project with a lot of files?
Actually, you can add folders to F# projects but it's not supported directly through Visual Studio (you have to edit the project file yourself): http://fsprojectextender.codeplex.com/ (edit: old link was broken, updated to F# Project Extender home page which has links to the original blog posts which were moved) (which I found in this answer).
I do this myself, but it is cumbersome and you end up avoiding it until keeping sanity really demands it. I think the feature simply slipped, or perhaps there wasn't as much a culture for folder organization with the F# designers in the first place. You can see in the F# source code that they favor huge source files with no directories, with separate projects as an organization boundary.
I imagine the F# project template could be modified to support this, and it is certainly something I'd like to see happen. At the same time the linear compilation order F# enforces causes your code to be somewhat self-organized, and so folder grouping plays a less significant role.
Manually editing the .fsproj file as described in Stephen's answer is one option (and I used it when I wanted to organize one larger project).
However, you have to be a bit careful and I think you cannot add new files to the folders (creating a file by hand and then adding an existing file works). However, if you like to keep things organized (like I do), then it should work for you.
Additionally, there is also a tool called F# Project Extender that should make things a bit easier for you . I have not tried it yet, but it looks like it supports adding folders (and perhaps other useful things). See for example this blog post by the project author.
So we have this tool, it's a web page, we drop a large piece of text in textBox a (say sql) run the tool
and it generates the guts of a code file in TextBoxb (say a custom view class model).
it's written in C#.
I know there are several ways to create visual studio extensions.
What I'd like to know is, what's the best/easiest/fastest way to take a c# dll that has a method that takes text in and returns text out, and turn it into a VisualStudio extenson, that takes text in and creates a files, adds it to the project and puts the text into it.
We're using Vs2008 and VS2010, and I'm okay the best soloution only work on 2010.
The closest I've found by googling so far is this:
http://visualstudiomagazine.com/articles/2009/03/01/generate-code-from-custom-file-formats.aspx
but they are for custom file formats only, i want to generate*.cs and *.rdlc and similar files.
I'd also like to be able to add methods to an existing class.
tutorial walkthroughs or better approaches woud be greatly appreicated.
VS package Builder is the answer. Lots easier.
I installed WiX 3.5 with Visual Studio 2010, as I've read lots of people saying that WiX is a great alternative to that hellhole that is the Visual Studio Setup project, but it sure seems like it requires a lot more effort to make even the simplest installer. Am I missing something?
In a VS setup project, I can add a project output to my ProgramFilesFolder, and VS automatically sweeps up all the dependent dll's from the other projects in the solution, as well as 3rd-party libraries and such. After reading this from the (apparently somewhat out of date) online docs, I thought maybe WiX finally had something similar, but it doesn't actually pull in dependent libraries--it just makes it easier to add that single project's output to a fragment without a lot of extra typing.
So the best I can see to do is manually add to my WiX setup project every single project in my solution that I want in the installer (and set Harvest to true, since that doesn't seem to be the default). I'd probably write a little perl script to do that. Then I have to determine all the non-project dependent dll's somehow (probably easiest to look at the VS setup project for that) and add by hand some wxs code to include them (since apparently the WiX project only handles references to projects, not raw dll's). Then edit in a simple UI, for which there are samples on the web I can work from. And code for shortcuts.
Is there a better way?
This is a very subjective and long answer type question. From a quality and capability perspective, WiX kills VDPROJ. From a learning curve perspective, not so much.
Check out IntallShield 2010LE ( Limited Edition / Free ) or look at Industrial Strength Windows Installer XML ( IsWiX ) (Disclaimer: I am the coordinator ) I use this tool to do the majority of my heavy lifting and then write small amounts of WiX by hand to glue it all together.
Is there a pre build action or some compiler switch that we can add?
I have just too many projects in our solution at the moment. I want to add new modules and compile them into separate assemblies.I am looking for options where I can avoid adding new projects for each assembly.
I am using Visual Studio 2005.
Also, It will be worthwhile to know if 2008 has better features over this space.
edit #1: There are two development teams working on this project and we want to cut the modules broadly into two verticals and keep the assemblies separate so that the ongoing patches ( post release ) do not overlap with the functionality in two verticals and also the testing footprint is minimized.
Currently the solution has about 8 projects and we need to setup the structure for the second team to start development.
I do not want to end up adding 5 or 6
new projects in the solution but
rather create folders in the existing
projects so separate code for the new
team or some easy way.
No, Visual Studio is still "one project per assembly". Do you really need to have that many different assemblies?
You may be able to write your own build rules which create multiple assemblies from a single project, but I suspect it's going to lead to a world of pain where Visual Studio gets very confused.
If you could give us more details about why you want lots of assemblies, we may be able to help you come up with a different solution.
EDIT: Having read your updated question, it sounds like you would possibly be better off just working off two branches in source control, and merging into the trunk (and updating from the trunk) appropriately. Alternatively, if the two teams really are working on independent parts of the code, maybe separate projects really is the best solution.
One of the problems (IMO) with Visual Studio is that the files in the projects are listed explicitly - which means that the project files become big merge bottlenecks. I prefer the Eclipse model where any source file under a source path is implicitly included in the build (unless you explicitly exclude it).
Neither Visual Studio 2005 nor 2008 lets you create multi-file assemblies. However, you can run the C# compiler at the command line with the '/addmodule:ModuleName' switch and it'll do what you want. For general details on command line usage of csc see this article. For description of the /addmodule switch see this one.
That said, however, you're most-likely taking a non-optimal approach here. In normal situations you should not have to want to create multi-file assemblies just because you have too many projects. Give more details of your general problem so that people can offer suggestions regarding that.
I'd heed the advice you've been given thus far--if you find yourself asking such questions, there's probably a deeper design issue that's being overlooked--but if you really must do what you're suggesting be done, you have several options. You can hack the project file to allow you to compile files into separate assemblies: the project file is an msbuild file, so there's a lot you can do with it. Also, you can simply use an msbuild file for building your projects and solutions. Or you can use a different build system entirely--NAnt is one example.
The likely problem with these suggestions is that they won't be feasible for your work environment. It's no good to start hacking away at project files that other people on your team use, or to just decide that this or that solution is going to be built using your custom msbuild file. There are many good reasons to use something like a single custom msbuild file, or NAnt, to build your projects, but it's always the wrong decision if it's not made with input from everyone the decision affects.