I'm wondering if adding .csproj files in the git history is really useful / best / bad practice
(Currently, I'm using git for private repositories)
Thanks!
Short answer: You definitely need .csproj files in your git history.
Long answer: Here's how to answer a question like that. Make a copy of your solution folder. Delete any files you wonder if they should be included in the git history. Try to build and run your code. If you can't, that means they are needed in git, and vice-versa.
In this case, you would discover that your project will not build without the .csproj file, hence that file must be in git.
It's also important to remove from git files that are not needed to build and run the project, such as files that are generated as part of the build process.
For the most part, this work has been done for you already, for example https://github.com/dotnet/core/blob/master/.gitignore has a list of directories and extensions that should be ignored for .Net Core projects. Other platforms/languages have similar .gitignore files posted.
In addition to the answer above, it helps to know what project files are:
When you create and build solutions in Visual Studio, Visual Studio uses MSBuild to build each project in your solution. Every Visual Studio project includes an MSBuild project file, with a file extension that reflects the type of project—for example, a C# project (.csproj), a Visual Basic.NET project (.vbproj), or a database project (.dbproj). In order to build a project, MSBuild must process the project file associated with the project. The project file is an XML document that contains all the information and instructions that MSBuild needs in order to build your project, like the content to include, the platform requirements, versioning information, web server or database server settings, and the tasks that must be performed.
Ref to more details (.Net): Understanding the project file
Similarly for .Net Core: Project files
Hence the reason why (emphasis mine):
In this case, you would discover that your project will not build without the .csproj file...
Hth...
Related
Original unedited question:
Full disclosure, I am a java developer learning dotnet core, on a mac with vscode. I get what the purpose .csporj file is, but I cant seem to find any information on why I need to maintain a .sln file.
Ok so maybe I need to make this more explicit.
I am not using Visual Studio. I am using vscode.
https://msdn.microsoft.com/en-us/library/bb165951.aspx contains no references to vscode. Everything I found said that the solution file was for Visual Studio, which to reiterate, I am not using. I updated the title to make this more apparent.
So is there a purpose for the solution file in vscode?
The sln is the equivalent of your eclipse work-space in Java, the csproj is the equivalent of a single java package. The sln is used to tie the source code for multiple assemblies together (for example a executable and its dependencies) in to a single project that can be opened as a whole.
You don't need the sln if you are working with a single project (but visual studio will still want to make one when you open a csproj by itself), but if you are working with multiple csproj it is needed to keep the projects together.
I am trying to set up a Visual Studio 2015 solution in the way that StyleCop checks for the C# style and once committed to the source control other developers don't need to do anything else to follow the same style rules and get the same errors/warnings from StyleCop automatically.
As the StyleCop documentation page and GitHub StyleCop describe (both actually say the same) under the title Team Development:
copy all of the files from {Program Files}\MSBuild\StyleCop into a custom folder
in my case under C:\Program Files (x86)\MSBuild\StyleCop\v4.7 there is just one file: StyleCop.Targets
Searching for any StyleCop.dll drives me to another folder (C:\Program Files (x86)\StyleCop 4.7) with many subfolders, dll's, xml, exe, lex...
Now my questions:
Which are exactly the needed files to be uploaded into the project and hence to the source control?
Which are the changes to be done in the configuration project?
Note:
Until now I see the contextual StyleCop menus that allow me to make code analysis and checks.
To use the install, you would need to have each developer install the StyleCop program on their machines, (and on any build server).
There is an easier way... instead use the StyleCop.MSBuild nuget package for each project:
This adds a StyleCop directive to each csproj, pointing at the instance within the packages folder, this means that it is transferable to each dev machine, and any build servers without them needing to do anything.
Then once there is no errors in a project, use StyleCop.Error.MSBuild to keep it that way, again from nuget:
This adds <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings> to the csproj, but again keeps it within nuget which I personally find an easier way to track things.
I have a very huge application, having more than 400 different projets. Most of them have been developped in very small solutions, much of them having only from 2 to 5 projects and all having a project called "Main", which is the startup project that calls the other one, for loading time purposes and efficiency.
I have added all of those 400 projects to my TFS build definition manually.
Now comes 2 questions :
1- It seems in TFS that my projects needs to be placed in the good build order in my build definition? TFS does not automatically detect the dependencies, as my little NAnt was doing all alone??? Do you imagine having to figure out the right build order for a solution containing 400 projects? This would be easy if they would have been in the same solution, but that is not the case.
2- We use third parties assemblies (Dlls). I have added a folder names "CommonDlls" into my TFS workspace. My builds starts correctly and starts compiling my first projects and sending them into the "bin" directory of the build. Perhaps, when the build trys to compile the first project referencing a 3rd party assembly, it cannot find it... Is there a way in pre-build script to copy the files located in the "CommonDlls" folder to the "bin" outdir of the build? Will TFS use those Dlls when compiling each project or it really tryes to use the referecend path into every single project?
Let's say my project on my development machine as "c:\TFS\bin" as a reference path where are located all dlls, will TFS try to look for that folder or it will use the outdir (it's own created bin folder) ?
The most effective way is to package the DLL's logically into NuGet packages. You can then store them on a file share and configure Visual Studio and you build server to fetch the correct ones at build time. This negates the need to burden your source server with big binaries and allows the server to cache the packages between solutions.
I have a sample project that is structured like the below image:
The WebApplication2 has depended on ClassLibrary1 at publishing time like this:
I want to copy some needed file in ClassLibrary1 project after publishing in a specific folder, for example in Plug-in/ClassLibrary1/
If you've looked at Orchard you'd see something like this.
Thanks.
In general (regardless of the type of the application) you could define custom actions during deployment, if you build a setup application. I think that limited edition of the InstallShield is the default solution for VS2013. There you could create some custom actions writing a script. Inside this script you could deploy the specific file. An alternative against the InstallShield is the WiX which you could use to build an MSI file using an XML.
Regarding web applications in particular, you could use the publish mechanism provided by the Visual Studio. This tutorial describes how you could configure it so that it would copy all project files. Then you could add the specific file as a project file and copy it each time you publish your website.
Hope I helped!
Got a Visual studio 10 solution for ASP.NET web site, and VS seems to compile *.aspx.cs files that are in the web site folder, that used to be part of the solution but were excluded (I no longer see these files in the solution explorer). Is it expected? If not, how could I fix it? Rebuilding solution does not help.
Also, is it expected that I cannot find the binaries for *.aspx.cs files?
If your website is a Web site project as opposed to a Web application project (see Web Application Projects versus Web Site Projects in Visual Studio) then IIS will perform the compilation at runtime for you instead of Visual Studio - in this case the .csproj file is not used to determine what is and isn't compiled.
There is no project file (.csproj or .vbproj). All the files in a folder structure are automatically included in the site.
I'm not sure where the compiled binaries go, but I believe that it is a temporary folder somewhere, so you shouldn't necessarily expect to see those binaries in the web site folder structure.
If you want explicit control over what is compiled and when it is compiled then you may be better off converting your project to a web application project.
Short answer: No. It only compiles whatever is is included in the .csproj marked as 'compile' (in the file properties window).
Try to refresh the project, open the .csproj as a file text and check if those files are referenced there.
Lastly, it might be a dependent project that references those files.
If you can't find the solution, paste the exact error given by VS
For clarification, solutions files (.sln) contains project files (.csproj); .csproj files are the ones that contain references to the files to build.