We use the built in table adapter wizard in VS2005 to build a portion of our app, resulting in an enormous .xsd file being generated.
It's never interesting to have this .xsd included when searching through code, so I would like to be able to skip it when using Visual Studio Find. Is this possible?
The only solution I could find is a workaround: Download the free baregrep program and use it to search your source directory. You can set baregrep to search only .vb files and even though it searches the designer files (which you probably do not want) you can see which source files you need to search individually. Baregrep is a really fine search program, handy to have on your machine.
Seems the best solution is to switch from Quick Find to Find In Files which gives us the "Look at these file types:" option. Instead of one of the defaults:
*.vb;*.resx;*.xsd;*.wsdl;*.xml;*.htm;*.html;*.css
Set it to just:
*.vb;
Related
I need to include all the output from some of the programs projects in the installer... my question is similar to the one in this post: How to add a whole directory or project output to WiX package
However, I am afraid I don't really understand the answer given in this link. From all the reading I have done, I think I need to use Paraffin to do this. But is there a "start from the very beginning, how-to" resource for using paraffin?
I have read this page: http://www.wintellect.com/CS/blogs/jrobbins/archive/2008/12/22/paraffin-3-0-now-with-full-wix-3-0-support.aspx
and one of the posts mentions calling paraffin from a bat file. Is this how one would "use paraffin" in their installer? If it makes a difference, I have been using Visual Studio to work on this project, and am also not sure how to use command line from within Visual Studio. Does anyone have any resources for a very new beginner? Thanks.
I ended up including each .dll and .exe manually, since they don't change very often. It was fairly easy to format them in this style:
`<File Id="WhateverId" Name="NameToDisplayAfterInstall" Source="$(var.ProjectName.TargetDir)Filename.ext" />`
I used Excel to format a list of files quickly and easily. I put all of these File tags in the <DirectoryRef Id="INSTALLLOCATION">
tag.
I did figure out how to scrape all the dlls and exes from the project output by using Heat (not paraffin) and harvesting a directory, not a project. Harvesting a project yields only the main exe and dlls. The problem with harvesting a directory, at least in my case, is that I ended up with a lot of excess files, (like .pdb and .xml) that I didn't want.
Basically, I want one of my folders to appear above the other folders as a type of "special folder", similar to how Properties has it's own special place even though it's a folder, same with App_Data, etc.
Is this possible?
By default, Visual Studio doesn't support adding special project folders. The Properties folder is hard-coded to behave the way that it does.
However, anything is possible with code. You could build an extension to do this, but it wouldn't be simple. You'd probably need to mess around with the IVsHierarchy or even implement a project subtype.
Basically, I want one of my folders to
appear above the other folders as a
type of "special folder", similar to
how Properties has it's own special
place even though it's a folder, same
with App_Data, etc.
Is this possible?
Yes:
Do it manually through the IDE
Write your own script to
generate/modify your *.sln/*.vcproj
For (1) "manual" on solutions in the IDE: Solution Explorer, right-click on Solution node==>Add==>New Solution Folder.
While typically the folders are sorted alphabetically (I'd insert a leading underscore to force your special folder to the top), solution folders inserted manually on my MSVS2008 leave the new folder "at the top", even though it should have bumped down when alphabetically sorted. However, folders under a Project (which are called "Filters") are always sorted alphabetically, and added similarly from the right-click, and then you can modify their "filter properties" with file name globs for what you want in there (e.g., add a filter glob for "*.MY_EXTENSION1;*.MY_EXTENSION2").
We chose (2), and we generate our own *.sln and *.vcproj, adding our own folders/filters. I've not seen any utilities on the web to help with that (so we had to write our own). The formats are not too hard to reverse engineer, but it's largely undocumented XML, so you have to experiment. There are only a couple good web articles explaining what's in the file, like this one:
http://tim.oreilly.com/pub/a/dotnet/excerpt/vshacks_chap1/index.html?page=4
On the "bright side", the files are only XML, so in developing our scripts we merely made changes through the IDE, saved, and compared the "diffs" for what change we want. Those changes are what our scripts insert when we modify our files. So, if you modify the file manually, you can similarly just "diff" the file to see what changed, and make your own script. (IMHO, this is the fastest and easiest route, since tools generally do not exist to manipulate these files.)
Tools like CMake and QMake generate *.vcproj/*.sln, but don't really do the folder customization thing like you're talking. However, we look at their output too, because, "there's more than one way to do things" in these files, and the files seem to have many undocumented features for doing different clever things that somehow these tools have "discovered" (so you can try to copy their generated output).
We found the .NET APIs to work with these files as too much work, and not really designed for that type of manipulation, but YMMV.
VS 2012 has a feature that I just found, and it solved this problem for me. It may not be new to VS.
Create a folder under the project with a leading "_" (to get it sorted first).
On the folder's properties set "Namespace Provider" to false.
VS (or ReSharper?) code analysis then does not complain that "the namespace does not match file location", which was the source of irritation for me that would otherwise have kept me from going this route.
Although there is no easy way to add Custom Folder, there is an easy way to "steal" Properties custom folder.
Add a regular folder to the project. For example MyCustomerFolder.
Open proj file xml. Find line
<AppDesignerFolder>Properties</AppDesignerFolder>
replace with
<AppDesignerFolder>MyCustomFolder</AppDesignerFolder>
Reload the project.
Now you've got a custom folder, that will always stick to the top.
This is not a work-stopper in any way, but I thought I should ask anyway because it is a little annoying. Let's say I create a new project and start putting source files in a directory other than the default that shows up the first time. Afterwords, whenever I open the project, I have to navigate to the source directory once during that session. Like I said, not a big deal (but if solvable, then it's icing on the cake). Quite a few times I absentmindedly put the source file in the default directory and end up committing that file to the SVN and if I am lucky, going through all the files, removing them, then adding them again.
So my question is, is there any way to specify the default source directory on a per project basis?
I have run into the same nuisance. I like to put the public interface header files for a library in a separate directory, but end up with file directory typos because I forget to navigate to the correct directory when saving a new file. Unfortunately, Visual Studio does not offer a setting to change the default directory for new C++ source files.
I had the same problem when I started using build systems (CMake, Premake) which requires me to keep my project files separate from my source files, which hampered my workflow.
Although changing the default source directory seems impossible, if you aren't afraid to spend money, the workaround I found was to use the Visual Assist extension.
You can bind a shortcut of your choise to the Create File command which creates
a new file relative to the directory or your open file.
I'd also recommend to base one's workflow around the wonderful
Create from Usage command (which I think greatly boosts
productivity) which almost eliminates the need to manually create files.
The extension is great, albeit a bit costly. I would love to see Microsoft incorporate these features directly in the IDE eventually as they are found vanilla in a lot of other IDEs e.g. Eclipse, Intellij.
There might be some free extensions available that does the same thing, but I haven't found any.
Changing the Default Project Folder may help. This page demonstrates how to change the default for Visual Studio 2005, and it should be the same for later versions.
I've got a relatively simple project that is under source control (svn), and I wanted to create an installer. I know that I could (should) use WiX, but as I'm new to creating installers I thought it'd be easier to just use the built-in Visual Studio (2010) Setup and Deployment Wizard.
Unfortunately, it seems that files including external (non-project maintained) documentation, configuration files, and "Content" files are added with absolute paths. This, of course, is suboptimal. I searched the web, but found only the same question, without an answer. Another stackoverflow user seems to have asked a similar question, but the only answer, which suggests ClickOnce, seems off-base (I'd like to have an MSI that I distribute not a web-based installation).
Does anyone know how (or whether) this can be fixed?
With VS2005, sometimes the paths stored in the vdproj file were absolutes, and sometimes relatives. In my case, it seemed to be related to whether the files were accessed via the canonical path or not. Here's a concrete example:
Source is on C:\Views\builddir, open solution C:\Views\builddir\solution.sln and add files from C:\Views\builddir\.. and VS2005 would add relative paths into the vdproj file. However, if you map that builddir to a letter drive, for example, make a subst from C:\Views\builddir to s:, open the solution via S:\solution.sln, and then add files by navigating to S:\.., VS2005 would insert absolute paths into the vdproj files. Whether VS2005 displayed paths as absolutes or relatives had no relation to what it stored in the vdproj files.
So, it may well be that the problem comes down to what path you're using to open that solution.. opening \\server\shareddir\solution.sln might get different behavior than mapping \\server\shareddir to W: and opening w:\solution.sln.
You can always add the files, then use a text editor (e.g. notepad) to change the absolute paths in the vdproj file to relative ones. You'll be fine until you change that project again.
MS doesn't seem to really fix minor bugs like this so much as rewrite the code to introduce an entirely different set of bugs, so VS2010 might still act this way.
FYI, why would one want to map an absolute path to your builddir? It was a holdover from the bad old days when VS didn't do anything correct with relative paths.
As tzerb mentioned, the main source of confusion might be that paths show up as absolute under the property window inside VS, but when you look into the actual VDPROJ file you should see the paths show up as relative. However, as patbob mentioned, I believe the paths ARE stored as absolute when they come from a different letter drive.
It might be easier now but when you start bumping into the limitations of the tool it's going to get real hard. Let's not even talk about the bad practices it will encourage which could end up being real hard for the poor end user installing your product. You've got Visual Studio 2010 so InstallShield LE ( free ) would be a better choice.
Otherwise, to answer your question, it will only use absolute paths if it can't caculate a relative path. ( for example c:\foo\foo.vdproj consuming d:\foo.txt consuming c:\test\foo.txt should automatically be ....\test\foo.txt )
BTW, if you decide to check out WiX and want some "easy" check out my IsWiX project on CodePlex. I'm trying to bridge the feature gap between InstallShield and WiX.
I'm trying to build a small VS 2005 solution I've just checked out of source control, and I'm getting this easy to understand error:
...\AssemblyInfo.cs' could not be
opened ('The system cannot find the
file specified. ') (The file is fairly
obviously missing)
Because this file's automatically generated, I've never paid it much heed before, and in VS 2003 (which I still work with day to day - pity me) it never seems to matter if it's missing.
So 2 questions:
1. How can I get VS 2005 to regenerate the file.
2. Could anyone explain to me in a couple of sentences what the assembly info file is all about, why it's generated, why it's a good idea to have an automatically generated file critical to my solution building etc etc.
Thanks - Andrew.
Edit: OK, I've googling some more, and it's probably significant that this is in an Nunit Test Project.
Update: Deleting the reference in solution explorer an Alex suggested did the trick, and the project now builds, but I'm not entirely happy with that as a solution. If the file is so unimportant, why is it generated in the first place? And if the file does perform a vital task, what am I missing out on by just deleting it?
Also, is it even possible to get it back? Either by getting VS to regenerate it, or by manually hacking one up (possibly using another as a template)?
This file contains assembly-wide settings like assembly version, name, etc. It is automatically generated when you change those settings using properties pages of the project. You should have this file in the project with sort of transparent icon (I think it is in resource folder or something like this by default). Locate it in the project tree and delete it. Visual studio will stop looking for it during build.
PS: assuming the path starts with .. and not ... then this file should be located one folder up from the project in the source control. So you can try looking there.