We have a large server-side C# solution at work. It has multiple projects, each with its own sln file on the first layer of the application's directory. It also has a general all.sln which contains all the projects.
I have added a new project which builds successfully, but a sln file for this individual project has not been created. How can I create it in VS 2013, so it appears alongside the other sln files?
Any help at all would be appreciated. I need to do this so that the BAT file we're using has a sln file it can use.
You should create an empty solution, save it at the proper location with the proper name, and add the desired project to it.
To create the empty solution:
File > New Project >
Other Project Types > Visual Studio Solutions >
Blank Solution
Related
BACKGROUND
I'm mostly programming in embedded C/C++ but sometimes I have to do some C# programming for our API. For this I'm using Visual Studio 2017 to create an API DLL for our customers.
The C# API and our C/C++ firmware are using a common set of status codes. I have a Lua script that generates these codes to a .h (for C/C++) and a .cs (for C#) file so they always are in sync.
All source files that are shared across products and platforms are in a special project called "Common" (checked-in to Subversion).
When we create new projects and use any "common" file, we put them in a sub folder called "Common\" so we know that there is no point in messing with them. Subversion will check out these "Common" files as externals of a specific revision used by each project.
In C/C++ it's no problem at all to have source code organized in several levels of folders, all source files have a relative path to the root project folder.
THE PROBLEM
So in this C# project I organize the source code as usual:
ProjectRoot\source.cs
ProjectRoot\Common\EStatusCodes.cs
In the ProjectRoot\ we have all .cs files for this C# project, and in ProjectRoot\Common\ are the external files from subversion's "Common" project.
So after the checkout of the external EStatusCodes.cs into the ProjectRoot\Common\ folder I add it to the C# project by "Add->Add Existing..." and then I point out the ProjectRoot\Common\EStatusCodes.cs file.
The file shows up in the Project but for some reason Visual Studio has COPIED the file form the ProjectRoot\Common folder to the ProjectRoot\ folder and is then using the copy! (The file's path in properties is set to the ProjectRoot\ folder.
So If we add more status codes to the "Common" project, this C# project don't get the update because Visual Studio now always use the copied version of the file from ProjectRoot\ and don't care if ProjectRoot\Common\EStatusCodes.cs has been updated.
I tried to add the Common folder to "Properties->Reference Path", but it still copies the file every time I add it to the project.
Is it possible at all to have source files somewhere else than in the C# project's root folder?
In the Add Existing dialog, there should be a small down arrow next to the Add button. If you click this, you'll see an option to "Add As Link". This will add the file as a reference link to the original file and any changes to the original will reflect in your project.
We have a similar way in C# project: add existing file to project as "Add as link".
Please refer this link for more details:
https://grantwinney.com/visual-studio-add-file-as-link/
I'm using Visual Studio 2013 and I have a solution that contains multiple projects.
I would like to extract one project from a solution to create a new, separate solution, that would only contain this one project.
Does anyone know how to do this?
If by "Extract", you mean "Duplicate" your project and start a new solution with this project, here is what you can do:
Create a new solution in Visual Studio
Copy your Project folder in the root of the new solution
Right click on the solution => Add existing Project and select
the project file (*.csproj in this case)
Copy the project folder into separate folder, open the .csproj file, press CTRL + S, it will open the save dialog and you will save the .sln file. That is it.
Right click on any project, then Exclude from Project. The excluded files will be in the project folder. Move those files to another folder, in the way you want it. Then you can create and add those files in new project by Add existing item
I have multiple ASP.NET MVC5 projects that use several similar styles/scripts, and I think, for maintenance's sake, it'd be ideal to have a separate project in Visual Studio 2013 containing the LESS stylesheets and JavaScript files that can be shared between the two.
My setup is as follows:
Web.Project1
Web.Project2
Web.Assets //would contain LESS/JS files
Resources
Domain
Data
Any pointers?
I've been looking at adding as a link, but I'm not certain that would accomplish what I need.
I recently went through this process for a project of mine, and concluded that if your goal is simply to avoid duplication by keeping your code DRY then using linked files works great.
It's simple enough to do, but I'll write it up anyway as it might save someone some time.
Quick Summary
Create common Solution Folders containing the resources to be shared, or simply designate one of the projects to be the master.
Use "Add as Link" to add the shared resource files to each project as needed.
Add an AfterBuild task to each project file that will copy the linked files to project folders. This is only needed so that Visual Studio test/debug (F5) will work locally.
Detailed explanation follows:
Configuring Solution Folders for the Shared Resources
** Note that if you're simply going to share files directly from one project to one or more additional projects then you can skip this step.
Visual Studio solution folders do not have to reflect physical file system folders, but doing so will help preserve your sanity. So first create the folders on your local file system and copy the resource files into them. The new folders should be located under your solution folder. For example:
\MySolution
\Common
\Images
\Scripts
\Styles
Back in Visual Studio, right click on the Solution Items folder and use Add Solution Folder to replicate the new file system folders.
Next, add the files to the new solution folders by right-clicking each folder and using Add Existing Item to add the contents of the folders.
Add Shared Resources as Links
For each project that will use the shared resources, right-click the project folder and choose Add Existing Item. Browse to the common folder, select the desired files, click the drop-down arrow next to the "Add" button and choose "Add as Link".
You may get a source control warning about adding files that are outside of the project directory structure, but this can be ignored since the linked file will be under source control at its source.
Add an AfterBuild Task to Copy Files
When you publish the application to a server the linked files will copied to the project folders to which they are linked and everything works as expected. However, in the development environment the linked files do not physically reside in the project folders. So when you hit F5 to test your application in VS, the shared resources will be missing.
The simple solution is to add an MSBuild task to copy the linked files from their source after each build. This needs to be done to for each project that contains the shared resource links.
Right-click the project and choose Unload Project. Right-click the project again and choose Edit <ProjectFileName>. Scroll to the bottom and add the following (just above "</Project>"):
<Target Name="AfterBuild">
<!-- Copy linked content files to local folders so that they are available in the debugger.
This is only an issue when running the application locally. The linked files should
be automatically published to the correct folder when publishing to a web server. -->
<Copy SourceFiles="%(Content.Identity)"
DestinationFiles="%(Content.Link)"
SkipUnchangedFiles='true'
OverwriteReadOnlyFiles='true'
Condition="'%(Content.Link)' != ''" />
</Target>
** Copy task adapted from this link.
Save the project file then right-click and choose Reload Project.
I created a solution with following structure
Solution
Installer (VSIX)
Template One (sdk project)
One.vstemplate
Template Two (sdk project)
Shared
AssemblyInfo.cs
Now I want to link the AssemblyInfo.cs in the shared project to my vstemplates, because i want the same AssemblyInfo.cs in all my projects.
I dont want to have sevaral copies because of possible future developments.
Till now i tried to add the AssemblyInfo.cs as link, but the template build process still search in the project folder and does not find the file (Add as link).
In addition i tried to reference the file using "\..\Shared", then i got a error out of root path.
One way I does not try is to use prebuild commands to copy the AssemblyInfo.cs to each project folder.
Has anybody an idea, tipp or solution for this situation?
I get a working version by using pre-build commands to copy the files from shared to the single templates.
Any other ideas how to solve this request?
Sorry for the late response.
I tried to reference the AssemblyInfo by adding following code to the vstemplate file
<ProjectItem ReplaceParameters="true" TargetFileName="Properties\AssemblyInfo.cs">..\Shared\AssemblyInfo.cs</ProjectItem>
My current solution is to add to each project a pre build command
copy /Y "$(ProjectDir)..\Shared\AssemblyInfo.cs" "$(ProjectDir)AssemblyInfo.cs"
I'm new to Visual C# Studio (actually using the Express edition, but another developer is using the full version), and we are using version control (svn).
It's acceptable to me to add the project files to the repository, since this repo is just for the two of us using Visual C# Studio. But it feels like there are some irrelevant files in there. Can someone familiar with Visual C# Studio project files tell me which files can safely be svn:ignored?
Some suspect files:
project.csproj
project.csproj.Debug.cachefile
project.csproj.user
project.sln
project.suo
Content\Content.contentproj
I'm sure the .sln is required, but what's this .suo? and the .csproj? Can/should any of these be generated by Visual C# Studio on loading a project?
Dont include
bin
obj
*.suo
*.user
_Resharper* (if you have Resharper)
Include
*.sln
*.csproj
You can also check the .gitignore file for visual studio projects on github.
.csproj defines the project structure. It is vital.
This is what I add to my global ignore list in Tortoise SVN:
*.suo *.user bin obj *.pdb *.cache *_svn *.svn *.suo *.user *.build-res TestResults _ReSharper*
Shouldn't be versioned:
.csproj.user is the user's project file settings (e.g. startup project)
.suo is the user's solution file settings
Should be versioned:
.sln is the solution file itself (what projects it contains etc)
.csproj is the project file
I'm not sure about "contentproj" but it sounds like it's a project file which should be under svn.
The .sln file defines your solution together with the .proj files (one for each project), so keep them in your svn!
You can skip the .suo file (personal settings - binary anyway) as well as the bin or obj folders. Also the .cache files can be left.
Just to add, anything that gets regenerated at build time, should be excluded. For example, files generated from the prebuild event or in some cases a custom tool.
Needed...
*.sln - The solution file contains references to all the projects and dependencies between the projects.
*.csproj - The project files themselves. These tell what files are included in the project, references, and the build steps for the project.
Not...
*.suo - This is a user settings file...
You definitely need csproj files... You might want to try AnkhSVN or VisualSVN, those VS addins add only the required files to SVN.
Or you could remove files from your directory structure until it does not load anymore.
I suggest experimenting this way because it is a great way to learn how a solution is structures by VS.
I leave out the Visual Studio Solution User Options file (*.suo) and the binaries directories as they get recompiled everytime you build your solution (the bin and obj folders).
As this as not been indicated in other answers yet :
In the case you are using Visual Studio with Unity 3D, you can safely add both *.csproj and *.sln to the .gitignore file, on the contrary of the usual case.
Indeed, the project structure is managed by Unity itself, not by Visual Studio. The only consequences of keeping them in source control are conflicts, even more so if for some reasons different Visual Studio versions are being used among commiters.
Example .gitignore for Unity 3D : https://github.com/github/gitignore/blob/master/Unity.gitignore
We also work with Visual Studio C# and SVN and I don't know about all the project files, but we only exclude the complete bin directory.
Check this out - type visualstudio amd you will have a .gitignore file generated for you, also you can concatenate multiple languages/ide' ignore files together if you have a solution which contains multiple languages.