I am a Visual Studio noob. My background is more Unix-related and mostly used to building things via scons or make. I don't even have much Eclipse experience.
Anyway, I am frustrated how it seems very difficult to move files between projects in VS. (I am running Visual Studio 2013). For example, suppose I have a ProjectXRel (release) and I want a ProjectXDev (development). I want them both to be runnable, and the dev version might have just a few editing changes that differ it from the rel version.
The intuitive thought is to just copy the files from ProjectXRel to create ProjectXDev, but VS seems to fight me on that (it wants to rename all the namespaces to the title of the project).
Also, some of the files, like .cs files derived from .dbml via OR designer, seem uncopyable, and rely on one replicating the process of using the utility to having valid files. I'm used to a project being defined by its files, but that's not really the case in VS. Instead it seems defined by process steps used to create and organize the files.
Also, do serious developers just use command line calls and powershell? That's seems harder, but at least you know what the %#$$# is going on.....
So, the basic question is, how does one replicate an existing project to produce a similar one for development purposes? (I know source control such as git could help with that, but that's not an option for this situation.)
Thanks!
You should be using the same project for both Development and Release.
The things that are different between Development and Release should be stored in a config file (web.config or app.config, depending on what type of project).
You should then be using Configuration Transformations to transform that .config file into Development or Release.
In Visual Studio, right click on the project and click Add New Item, select "Application Configuration File".
In this file you can put connection strings or key/value pair settings in the AppSettings element (MSDN Link).
Once you have your basic settings defined, you can then right click on the config file and click Add Transformation. This will add transformations for each of the Project Configurations you have. (by default Debug and Release).
It will look like this:
Now you can build deployment packages.
Or install Slowchetah and then when you press F5 to debug it will run the selected project configuration with the configuration transformation applied.
We recently switched to team foundation server 2010 for our source code management, everything works just fine, except for some legacy code written in FoxPRO 7 and 9, source code files are some sort of tables. For Forms, there are two kind of files, one ending in .scx and another in .sct, both can be explored using the fox studio but there is no way to open them in a text editor.
does anyone have any experience getting the fox code to work/merge... on TFS ?
I'm not aware of all of the ins and outs for source control and FoxPro, but if some of the source is binary, you can configure file extensions to disallow merges.
Right-click on the collection (root node) in the TeamExplorer window. Go to Team Project Collection Settings | File Types.
You should be able to add the extensions (like .sct), and specify that merging and multiple checkout is not allowed for those files.
The downside will be that only 1 person at a time can check those files out, but since the forms are FoxPro tables, I would imagine that's the same problem that you would have with any source control tool.
For merging you can set up a merge tool that is capable of merging those files. This must be done on every developer station (Tools->Source Control->VS Team Foundation Server->Configure User Tools).
It may be that VS uses a server-side merge tool to do auto-merges, I don't know if or where you can change that.
I've worked with VFP since it was FoxBase back in late 80's. Visual Foxpro used .dbf files (renamed extensions) for purposes of building forms (.scx/.sct) and visual class libraries (.vcx/.vct) and reports (.frx/.frt).
I've written some code to run through a given project and dump out a text version of all the code as if it was all text-based. All the controls are dumped in alpha order, embedded procedures, etc too. List all property settings in same place too.
Its not PERFECT, but I've used over the years in comparing source code versions when dealing with other developers who liked to change things and not notify me (or others) of such changes and finding later by other horrendous means.
If this is something you might be interested in, I can strip-down the code (some) and send it to you via an email, but would need an email address. The code is written in VFP as a .prg file, so nothing compiled that you would need to worry about any viruses or anything.
At least this way, you COULD get a text version associated with the binary pair's of files used within VFP.
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 am currently working on some LaTeX document which embeds C# files generated by Visual Studio 2008. My problem is that these files are encoded in UTF-8 with BOM. This causes LaTeX to produce output similar to the output described in this post:
Invalid characters in generated latex sources in Doxygen?
I know that I can use a tool like Notepad++ to convert the file to ASCII or some other format without BOM. But my intention would be to:
either cause LaTeX to use correct input encoding (until now I failed doing it with the package imports like:
\usepackage{ucs} % unicode functionality
\usepackage[latin1]{inputenc}
or cause Visual Studio to save the files without BOM or in plain ASCII
Otherwise I might edit the file (compile it and save it in VC#) and unintentionally introduce BOM again, which would break the code listing in the document.
Many thanks,
Ovanes
Visual Studio does not have this option, by design I believe, because .NET is built from the ground-up to use Unicode.
However, I don't believe Visual Studio is supposed to use the byte order marks. You said that Visual Studio is "generating" these files, but what process is really creating them? Is it the result of some sort of code generation tool? If so, that's the culprit and the place where you should focus.
I checked several of my code files and none of them contain the byte order marks.
EDIT: Changing Visual Studio Project Templates
In the comments the questioner said that these files were generated by the built-in Console Application project template. These are stored on your hard drive and can be modified if necessary.
Your installation path may vary, but on my system, I navigated to this directory:
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ProjectTemplates\CSharp\Windows\1033
Here I find ConsoleApplication.zip. I copied this to my desktop (for safety) and unzipped, and inside you find 4 files - a .vstemplate file, and the 3 files that are created by the project: AssemblyInfo.cs, ConsoleApplication.csproj, and Program.cs.
If you want, you can edit these files to remove the byte order marks, zip it back up, and replace the file in the source directory.
OR, to be safer, you can change the name of the template to "Console Project - No BOM" or something like that. In the .vstemplate file, there is a Name attribute that uses a Package attribute to call in information from somewhere by a guid. You can replace this name line with a simple line that specifies the name.
<Name>Console Application - No BOM</Name>
Then rezip the files, and put the zip file in the following path:
(My Documents)\Visual Studio 2008\Templates\ProjectTemplates\Visual C#
New projects created from this template should not contain the byte order marks, but remember, Microsoft apparently wanted those byte order marks in there, so your mileage may vary.
Item templates (like Class) can be modified in the same way - it shouldn't take too much exploring to find the default and user ItemTemplates directory.
I'm not sure I understand your scenario. But if you simply want to convert a file to ASCII from within Visual Studio select "File - Save As" and switch the encoding to ASCII.
have you tried \usepackage[UTF8]{inputenc}
In VS 2015 you can specify encoding using File -> Advanced save options... dialog
You can use the plugin for Visual Studio: https://vlasovstudio.com/fix-file-encoding/, this plugin prevents Visual Studio from adding BOM to the beginning of the file, so that way all of my files can have UTF-8 encoding and raw strings can contain special character and they will be displayed/written without any issues,
Visual Studio solutions contain two types of hidden user files. One is the solution .suo file which is a binary file. The other is the project .user file which is a text file. Exactly what data do these files contain?
I've also been wondering whether I should add these files to source control (Subversion in my case). If I don't add these files and another developer checks out the solution, will Visual Studio automatically create new user files?
These files contain user preference configurations that are in general specific to your machine, so it's better not to put it in SCM. Also, VS will change it almost every time you execute it, so it will always be marked by the SCM as 'changed'.
I don't include either, I'm in a project using VS for 2 years and had no problems doing that. The only minor annoyance is that the debug parameters (execution path, deployment target, etc.) are stored in one of those files (don't know which), so if you have a standard for them you won't be able to 'publish' it via SCM for other developers to have the entire development environment 'ready to use'.
You don't need to add these -- they contain per-user settings, and other developers won't want your copy.
Others have explained why having the *.suo and *.user files under source control is not a good idea.
I'd like to suggest that you add these patterns to the svn:ignore property for 2 reasons:
So other developers won't wind up
with one developer's settings.
So when you view status, or commit
files, those files won't clutter the code base and obscure new files you need to add.
We don't commit the binary file (*.suo), but we commit the .user file. The .user file contains for example the start options for debugging the project. You can find the start options in the properties of the project in the tab "Debug". We used NUnit in some projects and configured the nunit-gui.exe as the start option for the project. Without the .user file, each team member would have to configure it separately.
Hope this helps.
Since I found this question/answer through Google in 2011, I thought I'd take a second and add the link for the *.SDF files created by Visual Studio 2010 to the list of files that probably should not be added to version control (the IDE will re-create them). Since I wasn't sure that a *.sdf file may have a legitimate use elsewhere, I only ignored the specific [projectname].sdf file from SVN.
Why does the Visual Studio conversion wizard 2010 create a massive SDF database file?
No, you should not add them to source control since - as you said - they're user specific.
SUO (Solution User Options): Records
all of the options that you might
associate with your solution so that
each time you open it, it includes
customizations that you
have made.
The .user file contains the user options for the project (while SUO is for the solution) and extends the project file name (e.g. anything.csproj.user contains user settings for the anything.csproj project).
This appears to be Microsoft's opinion on the matter:
Adding (and editing) .suo files to source control
I don't know why your project stores the DebuggingWorkingDirectory in
the suo file. If that is a user specific setting you should consider
storing that in the *.proj.user filename. If that setting is shareable
between all users working on the project you should consider storing
it in the project file itself.
Don't even think of adding the suo file to source control! The SUO
(soluton user options) file is meant to contain user-specific
settings, and should not be shared amongst users working on the same
solution. If you'd be adding the suo file in the scc database I don't
know what other things in the IDE you'd break, but from source control
point of view you will break web projects scc integration, the Lan vs
Internet plugin used by different users for VSS access, and you could
even cause the scc to break completely (VSS database path stored in
suo file that may be valid for you may not be valid for another user).
Alin Constantin (MSFT)
By default Microsoft's Visual SourceSafe does not include these files in the source control because they are user-specific settings files. I would follow that model if you're using SVN as source control.
Visual Studio will automatically create them. I don't recommend putting them in source control. There have been numerous times where a local developer's SOU file was causing VS to behave erratically on that developers box. Deleting the file and then letting VS recreate it always fixed the issues.
No.
I just wanted a real short answer, and there wasn't any.
On the MSDN website, it clearly states that
The solution user options (.suo) file contains per-user solution
options. This file should not be checked in to source code control.
So I'd say it is pretty safe to ignore these files while checking in stuff to your source control.
I wouldn't. Anything that could change per "user" is usually not good in source control. .suo, .user, obj/bin directories
These files are user-specific options, which should be independent of the solution itself. Visual Studio will create new ones as necessary, so they do not need to be checked in to source control. Indeed, it would probably be better not to as this allows individual developers to customize their environment as they see fit.
You cannot source-control the .user files, because that's user specific. It contains the name of remote machine and other user-dependent things. It's a vcproj related file.
The .suo file is a sln related file and it contains the "solution user options" (startup project(s), windows position (what's docked and where, what's floating), etc.)
It's a binary file, and I don't know if it contains something "user related".
In our company we do not take those files under source control.
They contain the specific settings about the project that are typically assigned to a single developer (like, for example, the starting project and starting page to start when you debug your application).
So it's better not adding them to version control, leaving VS recreate them so that each developer can have the specific settings they want.
.user is the user settings, and I think .suo is the solution user options. You don't want these files under source control; they will be re-created for each user.
Others have explained that no, you don't want this in version control. You should configure your version control system to ignore the file (e.g. via a .gitignore file).
To really understand why, it helps to see what's actually in this file. I wrote a command line tool that lets you see the .suo file's contents.
Install it on your machine via:
dotnet tool install -g suo
It has two sub-commands, keys and view.
suo keys <path-to-suo-file>
This will dump out the key for each value in the file. For example (abridged):
nuget
ProjInfoEx
BookmarkState
DebuggerWatches
HiddenSlnFolders
ObjMgrContentsV8
UnloadedProjects
ClassViewContents
OutliningStateDir
ProjExplorerState
TaskListShortcuts
XmlPackageOptions
BackgroundLoadData
DebuggerExceptions
DebuggerFindSource
DebuggerFindSymbol
ILSpy-234190A6EE66
MRU Solution Files
UnloadedProjectsEx
ApplicationInsights
DebuggerBreakpoints
OutliningStateV1674
...
As you can see, lots of IDE features use this file to store their state.
Use the view command to see a given key's value. For example:
$ suo view nuget --format=utf8 .suo
nuget
?{"WindowSettings":{"project:MyProject":{"SourceRepository":"nuget.org","ShowPreviewWindow":false,"ShowDeprecatedFrameworkWindow":true,"RemoveDependencies":false,"ForceRemove":false,"IncludePrerelease":false,"SelectedFilter":"UpdatesAvailable","DependencyBehavior":"Lowest","FileConflictAction":"PromptUser","OptionsExpanded":false,"SortPropertyName":"ProjectName","SortDirection":"Ascending"}}}
More information on the tool here: https://github.com/drewnoakes/suo
Using Rational ClearCase the answer is no. Only the .sln & .*proj should be registered in source code control.
I can't answer for other vendors. If I recall correctly, these files are "user" specific options, your environment.
Don't add any of those files into version control. These files are auto generated with work station specific information, if checked-in to version control that will cause trouble in other work stations.
No, they shouldn't be committed to source control as they are developer/machine-specific local settings.
GitHub maintain a list of suggested file types for Visual Studio users to ignore at https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
For svn, I have the following global-ignore property set:
*.DotSettings.User
*.onetoc2
*.suo .vs PrecompiledWeb thumbs.db obj bin debug
*.user *.vshost.*
*.tss
*.dbml.layout
As explained in other answers, both .suo and .user shouldn't be added to source control, since they are user/machine-specific (BTW .suo for newest versions of VS was moved into dedicated temporary directory .vs, which should be kept out of source control completely).
However if your application requires some setup of environment for debugging in VS (such settings are usually kept in .user file), it may be handy to prepare a sample file (naming it like .user.SAMPLE) and add it to source control for references.
Instead of hard-coded absolute path in such file, it makes sense to use relative ones or rely on environment variables, so the sample may be generic enough to be easily re-usable by others.
If you set your executable dir dependencies in ProjectProperties>Debugging>Environment, the paths are stored in '.user' files.
Suppose I set this string in above-mentioned field: "PATH=C:\xyz\bin"
This is how it will get stored in '.user' file:
<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>
This helped us a lot while working in OpenCV. We could use different versions of OpenCV for different projects. Another advantage is, it was very easy to set up our projects on a new machine. We just had to copy corresponding dependency dirs. So for some projects, I prefer to add the '.user' to source control.
Even though, it is entirely dependent on projects. You can take a call based on your needs.