This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Which files in a Visual C# Studio project don’t need to be versioned?
when creating a repository, what do you include in the repository, should folders like Resharper, Debug and Bin folder be included? if not, is it possible to exclude files/folders from the unstaged changes check?
In order to ignore some files/directories, you have to create a .gitignore file ( http://kernel.osuosl.org/pub/software/scm/git/docs/v1.6.0.6/gitignore.html )
Depends on your requirements.
We mostly use C++ & SVN, but the idea should be the same for C# & git. We usually don't include debug/release & bin folders and .suo/.user files. We only include source/header files, resource files, data files and projects/solutions.
These are enough (as far as i can remember) for the others to checkout the project & compile themselves.
If you want others to be able to checkout the executables, you should add your bin folder too. But this causes a lot of conflicts between developers if they commit their bin folders because everyone is working on something else hence the contents of bin frequently changes.
As the other answers say you do not want to include bin folders, temp files etc.
The rule of thumb I use is to try to only check in code that is edited by humans, and everything else should be generated when you build the code. Obviously binaries get built for you but also things like autogenerated code should be created at build time. This isn't always practical, sometimes it is a lot easier to check in, say, a proxy to a web service to save having to build it everytime you recompile. You have to make compromises sometimes.
You should also avoid checking in any kind of local settings files generated by VS (e.g. .suo files). But DO check in project wide settings such as custom dictionaries and the like.
whatever can be generated/compiled out from you source code, don't source control it.
Related
I want to convert my program into something that I can give out and people can use (just to my friends and people I know) but I'm totally lost as of how to do it. I've tried doing lots of things from other forums but none seem to work or actually do what I'm looking for.
I tried using the publishing feature in the build tab but don't like that It makes It into a ClickOnce application as I'd much rather have it as an .exe.
From what I read there is already one of these in the bin\debug folder (I'd use the use the release bin\ folder when I am fully finished) but i don't know how much or what files actually need to be packaged together for it to work on another computer.
My main questions are:
Can I actually make a distributable a application using the bin\debug .exe with all the other files in it?
Do I also need to include the obj and properties folder? (I'm guessing not for the properties but the obj does look kind of important)
Because I've used NuGet packages and references do i have to to include the App.config and packages.config or is this just something that visual studio uses?
sorry if I've got anything wrong with what I've said, I'm way out of my comfort zone here.
For a console application, you should be able to zip up the contents of the bin/release directory and distribute it directly.
You can safely exclude .pdb files from your archive, though they can help you debug the program if your friends and cohorts encounter errors.
Sorry, a bit of a noobish question here...spent an hour on Google and in MSs help documents, my head appears to be in the wrong place, I can't figure this out.
I have a C# project set up in Visual Studio 2012 that has references to a few .dlls that I have on my own hard drive (NetOffice .dlls to be specific, for Excel Interop). I've been adding them by right clicking on my references folder, going to Add Reference and then going to Browse to find the files. At that point they are included and everything works as expected on my side.
The problem occurs when I share the project. I'm using Git to keep the project coordinated between myself and a couple team members. I'll run my commit and push it then have my teammate do his pull. Everything shows up on his computer correctly, but when we open up the project it tells me that the NetOffice .dlls are missing.
I'm guess that this is because the files are only linked locally on my computer, but I can't figure out, for the life of me, how to make the .dlls exist in the file structure so that they travel with the project when I push it.
We have a few NuGet packages we use as well, and they seem to work just fine after being transferred. I've also gone into the .dll properties for NetOffice and turned "Copy Local" to true, yet it's still not included.
All I want is to be able to link references and then send the whole thing (dlls included) to my teammate, what am I doing wrong? I figured I would want to simply include the .dlls in the project structure but... I'm just not understanding something. Any help please?
1 Create a folder in the file system at the same level as the solution file.
2 Copy the external dll's to that folder.
3 Add a Solution Folder tho the solution.
4 Add each dll to the the solution folder using add existing item
5 Reference the Dll's in the solution
The steps 3 and 4 aren't really necessary, but they help to keep things organized.
Lets assume your source control root folder is called SourceRoot
and your solution files are under a folder called JaySolutionFolder
I prefer:
Adding a new folder to your source control, under SourceRoot, called SharedDlls
Copy all external Dlls to this Folder.
Add this dll references form SharedDlls to your project.
Commit this folder
Now your teammates have to get JaySolutionFolder & SharedDlls to compile the sources.
Later this SharedDlls could be target directory of Build process (Using tools like TFS Bulid, NANT or else)
This will be a way to minimize team based development problems.
In release and software installation, you can use installers or software package builders like installshield or Visual Studio Setup Package or ... to solve external dlls problem
Hop this helps.
Although it's not good practise to include binaries in your git repository, doing so will solve your problem.
The quick fix could be to create lib directories in sensible locations within your repository (I'm not a C# developer but Gama Felix's suggestion seems correct).
Then commit these folders and push to the server.
I have a quick question regarding debug and release in VS 2008.
I have an app i've been working on - its not yet complete but the bulk of the functionality is there. So basically i'm trying to give a copy of it now to the person helping with documentation - just so they can have a play and get the feel for what i've made.
Now the question is how to provide it to them. I was told to just copy the .exe out of the debug/bin folder and put that onto USB. But when testing, if I run this .exe anywhere else (outside of this folder) it crashes. I've now worked out why this is:
var path = ConfigurationManager.AppSettings["PathToUse"];
var files = Directory.GetFiles(path);
throws a null reference, so that App.config file is not being used. If I copy that file in with the .exe it works again.
So actually my question is regarding the best way to manage this situation. What is the best way to provide a working copy to people, and, is there a reference on preparing apps for release - so everything is packaged together and installed in a clean structured folder heirarchy?
If you want to be safe grab everything in the debug/bin folder. If you use the drop down in VS to change to release and then compile the project, there will be fewer files in the release/bin folder because many debug related files are not included.
If there are third party DLLs you are referencing, like if you downloaded log4net or something like that, then you can simply put them in the same folder as the exe. This is called side-by-side deployment, and in my opinion is the simplest and easiest to test.
You can search for XCOPY deployment to learn more about what you are trying to do.
You can take another step of compressing the bin folder into an archive like a zip file to make it easy for the user to extract them, or you could use a tool like WIX or NSIS to create an installer to extract and copy the files.
I've created a Codeplex site for an app I'm building and right now I just right click the entire solution folder Visual C# Express created for me, and used that.
Now in my repo I have a lot files that I'm assuming will enable the user to compile my application on their end.
I heard I shouldn't upload the /obj folder and some other things.
What things are absolutely necesary for me to commit to my repository?
You should ignore the following, by setting the svn:ignore property on your project folder:
bin
obj
*.user
*.suo
You need the solution file, the C# project file(s), and all of the code files.
Basically, leave out the .suo file (with the solution), any user specific files (which will have your username appended to them, the bin\ and the obj\ folders. Everything else should be included.
It's common practice in organizations I've worked with to also include binary resources to which we don't have the source code and are required for the build in the source control. I'm aware that this is a somewhat controversial practice but it's worked wonders for us. Usually we keep them in a solution-rooted folder named 'Resources' or the like such that they're available for each developer to use when they check out the solution.
If you would use the Standard Edition of Visual Studio you could use the AnkhSVN Plug-In, but in Express this is not possible. :-(
So what you should exclude
folder obj
folder bin
file *.user
file *.ncb
Everything else has to be in your repository.
I'm building an application that is used by several different customers. Each customer has a fair amount of custom business logic, which I have cleverly refactored out into an assembly that gets loaded at runtime. The name of that assembly, along with a number of other customer-specific settings, are stored in the application's configuration file.
Right now, here's what I have to do in order to debug the application for customer foo:
Go to the filesystem in my project directory and delete app.config
Copy app.config.foo to app.config.foo - Copy.
Rename app.config.foo - Copy as app.config.
Tell Windows that yes, I want to change the file's extension.
Switch back to Visual Studio.
Open the Settings.settings item in my project.
Click "Yes" 13 or 14 times as VS asks me if I want to use the new settings that have been changed in app.config.
Close Settings.settings.
Okay! Now I'm ready to debug!
It seems to me that the rigamarole of opening Settings.settings is, or ought to be, unnecessary: I don't need the default values in Settings.cs to be regenerated, because I don't use them. But it's the only way I know of to make VS aware of the fact that the app.config file has changed, so that the build will copy it to the output directory.
There's got to be an easier way of doing this. What is it?
You can also let Visual Studio automate Robert`s approach by:
Define a Build Configuration for each client
In the post build event, simply xcopy app.config.xxx to your bin folder. Where XXX is the name of a Build Config accessible in VS. Something like: xcopy app.config.$(ConfigurationName) $(OutDir)/app.config
VS will drop a distinct build for your clients in separate folders, aolong with the proper config file.
bin/Client1/
bin/Client2/
You can refer this post for some good practices : Managing Multiple Configuration File Environments with Pre-Build Events
Thinking about the mess of managing multiple configuration files I made this tool: http://envride.codeplex.com/
Its purpose its exactly to make it easier to manage multiple configuration files in an automated way. I would be very pleased if you would take a look at it.
A couple of people suggested using multiple VS configurations, which I think would have worked, except that it would require me to rebuild the solution every time I switched between configurations.
What I did instead seemed a little stupid while I was doing it, but I've been using it for nearly a year now and it works extremely smoothly. In my project directly, I create a separate app.config.XXX file for each customer. The actual app.config file is used solely to generate Settings.cs - it has all of the correct setting names and their default values. It doesn't get copied to the build directories, ever.
Then I wrote a little program that lets me select a customer, and that simply goes through the directories for each project and, if I selected customer XXX, copies app.config.XXX to bin\debug\myprogram.exe.config and bin\release\myprogram.exe.config. As long as this program knows where the root of the solution is (I have to be a little careful whenever I branch the code), it works like a charm.
This thread is too old to represent current tools in VS.
You can use an addon that acts similar to web.debug.config but for app.config.
https://marketplace.visualstudio.com/items?itemName=GolanAvraham.ConfigurationTransform
And for the same app.config transformations without addon.
https://www.linkedin.com/pulse/multi-appconfig-visual-studio-2017-benjamin-davis/
You may opt to define multiple Visual Studio solution configurations, one for each customer, and have customised MSBuild targets for your Windows app project.
I have documented the steps of how I handled this here. Multiple app.config files for deploying to different environments
After a little digging and work around I got my Test project working with multiple configurations,
In the Configuration Manager, create the configurations you need
Copy paste your app.config and add the name of the configuration, in my case is AHI, FIV, MGC, so my config files look like: App.AHI.config, App.MGC.config, App.FIV.Config. You can name it how ever you wanted, but keep the same convention
Add a Post-Build event. In my case it would look like: xcopy $(ProjectDir)app.$(ConfigurationName).config $(TargetDir)$(TargetName).dll.config /y
here is my post, so you can read it with more details
Running a Test Project with Multiple Configurations