The problem I'm facing is that it seems that some of the files generated by Visual Studio are not necessary for commits.
Aside from the obvious things not to commit, what other files should I not commit? Do I need to commit .manifest files, etc.?
A different way of saying it: what files are needed to recreate the project I'm working on, and what files can be auto-generated?
Thanks!
The files I usually don't commit are: *.suo and *.user. I commit most other files.
Binary files can be committed or not depending on your company policy. In theory you should be able to recreate them again from the source code, but in practice it is a good idea to have an exact copy of anything you have sent out to a customer. So at least for releases the binaries should be committed.
In general, its a bit difficult to specifically list the files as it depends a lot on what kind of project you have and tools if any you use for autogeneration of code.
In general, the .suo file is something that is user specific and shouldnt be checked in.
However, the easiest way that i can suggest to you is to
Dont checkin any file that you arent sure u need.
Take a copy of all files from your source control into a fresh location.
Build the solution.
If it builds, great. If not, you then add files till it does.
It is a bit trial and error, but most likely its going to be only a one time thing.
Other option is to actually find out for each type of unknown file exactly what it does and then decide whether it is needed or not and accordingly exclude / include.
For this, if you post the extensions of the files you arent sure of, either google / SO can help!!
Personally, i dont believe in commiting binaries at all, even for releases. Seems unnecessary to me as in our case, every release has a label associated with it. So getting the exact code that was released is just a question of getting the code associated with the label and building it.
Also, since deployment is usually via setup files, as long as you have the setup msi / exe (and as long as you are keeping backups of those for your releases) having all the binaries checked in into source control seems a bit of overkill
Related
I´d like to check if all files in an specific tfs folder are "latest". If they are not (see picture) a get-latest will be executed. If they are all "latest" no get-latest will be performed.
The reason why I´d like to prevent always executing a get-latest is that it takes much time.
So what I need to know is whether all files are latest. I tried to get this information that way. Getting the latest-state worked well, but it took even more time than an get-latest itself.
Is there any way to get information about the latest-state of files hostet in tfs, without performing time-consuming operations?
If you want to know whether you're up-to-date without downloading files, then you can do a "preview get":
tf get /version:T /preview
This will tell you whether you're up-to-date or not, and if not, what you would need to download to become up-to-date.
But this strategy will not provide a benefit for speeding up your updates, it will be (net) slower than if you'd just done a get latest in the first place.
Get Latest (with preview) will ask the server what's necessary to do a get: the server will compute the differences between your workstation version and the server version and provide you with the list of files that you need to download.
Now if you were to turn around and do a Get Latest, then that will... ask the server what's necessary to do a get. It will recompute that list, and give you the list of files that you need to download. Now you'll actually download them and "complete" the Get by telling the server that you've updated your local files.
You've added an unnecessary round-trip and server computation to the mix.
Doing a "Get Latest" is the fastest possible route to updating your latest version information, whether you're already up-to-date or not.
A few months ago a developer pushed and merged a feature branch into our main branch (develop) that contained test files (800MB). I deleted these files from Bitbucket and everything (it was a pain). Now I am looking for a solution that could prevent this from happening in the future.
Is there some kind of process/script that I could run before performing a merge to my main branch? I would like this process to check every single file in the solution and verify that every file is less than 2.00MB.
Not sure if this will help or not, but the solution consists of various C# projects, including unit tests.
Use one of the git hooks to prevent this, either on receiving a push in the central repo, or before merging.
When troubleshooting our applications, in many situations I cannot be sure what branch the assemblies originally come from, due to an imperfect release cycle and human error.
(We have quite a lot of different bugfix/feature/test/release branches etc. in our TFS).
The PDB-files can help sometimes, in a test environment at least, but sometimes they're missing or outdated / belong to assemblies from another branch.
So, I was trying to think of a way to include the source branch information inside the assembly directly.
Surprisingly, I could not easily find a straight forward way online to accomplish this.
My answer below explains my approach. I would be happy about feedback or alternative solutions.
In short: I created a custom attribute that I put intoAssemblyInfo.cs. Inside the attribute's constructor, the server path for the current assembly is queried from TFS and compiled into it.
It's basically a combination of the following:
Can I add custom version strings to a .net DLL?
How do I get the path of the assembly the code is in?
Get TFS mapped folder of a local sub folder of the solution?
(Note: I cannot post the actual source code due to company restrictions, but I think it's pretty straight forward.)
To get the attribute's value later is unfortunately not as easy as getting the version number from the DLL-file's properties, but at least it is possible now to get the information I need with minimum effort. (I use a small PowerShell script for that.)
Having a server that other devs use, I currently log the version of the dll they use. I do that by having the client that use Reflection to retrieve its version:
Assembly.GetEntryAssembly().GetName().Version.ToString();
It's nice, but since it come from dev that uses TFS and do themself the build, I can not see if they have the latest version of the sources. Is there a trick, like a compilation tag, that would easily allow a hash of the generating source code?
Note: I have try to send the MD5 of the dll (using assembly.Location), but it is useless since the hash value changes between 2 compilations (I suppose there is some compilation timestamp inside the generated dll).
This is most collaboraton issue then a coding.
In the moment that you find out that the version is old one.notify them about it.
If the real version is not old one, that means that developers before making buold did not increment the version ID, which is mistake.
In other words, ordanize it among people, and not relly on these kind of tools (if there is any). You trying to create a complicated tool, that will help you avoid mistakes, but humans will find a way to make them again.
So it's better to create solid relation structure among you, imo.
Create a tool on pre build event to hash/last-write-time your code files.
Write the result to a cs file or a embedded resource file.
The result file must exclude in above action.
For prevent skip build (up-to-date) feature not work,Compare the file before write.
And if youre opening the file in IDE will get a prompt `changed from out side' when build.
Seem there is no easy way to do it.
I'm a beginner so if there is a terminology for what I'm doing I don't know how to search for it. So forgive me if this has been asked before. So here is what I do. Before I make any major code changes, I make a copy of the projects folder and call it "project v6" for example. Then if I really mess things up and cant find a way to undo it, I just go back to the previous folder. This has been working well enough for me but sometimes I forget to do this and have to take 2 steps back. Is there an easier way to do this than the way I am now?
There are many source control tools, which keeps track of all this stuff. Git, subversion, cvs (used wikipedia links, which explains each with more detail. This can be done much more easily once you get used to them.
In both there is commit what you've done to a server (which may be your own machine). But you can store your code somewhere else (so you don't lose everything, in case your hard disk fails or something like that). Google Code is a good example.
Git - harder to use, but very powerful (more used when there are lots of people working on the same project, and even the same file sometimes), much easier to deal with branches and stuff like that (if you don't know what that is, so you probably don't need it yet)
svn (subversion) and cvs - simpler to use, with fewer resources available. Probably enough for your needs
What you're looking for is revision/source control software.
http://en.wikipedia.org/wiki/Revision_control
I absolutely agree you need to start using a source control system. Even if for no other reason than to ingrain good work habits, you will be required at some point to use a source control system.
Having said, if your IDE is Visual Studio (non-express editions) you can use an addins to:
zip the sln for you, such as codeproject - zipstudio
or
keep a "local file history à la Eclipse" visual local history