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
Related
Currently, the developers of my team format their source code (C++, C+, stored in MS's TFS 2012) manually. We are now considering to use Visual Studio's auto formatting option (probably with Uncrustify as the pretty print engine). The idea would be to make sure that nobody has any outgoing changes, and then to format the whole code base and to commit the result. From then on, we would integrate automatic formatting into our workflow.
However, our fear is that we will afterwards not be able to easily find out who has done the last changes on a particular line of code using Source Control/Annotate (that information is often quite useful, e.g. for asking the according developer about that code).
So here are my two questions:
a) Does anybody have experience with introducing auto-formatting into a team's workflow (given an already existing and quite large code base)? Are there any best practices for this?
b) In particular: Is there any way to format our complete code base without loosing the history information? I could e.g. imagine a tool which would keep track of where each line has gone after formatting, and to adjust TFS's history such that that information is preserved. However, I haven't found anything like that by now.
Annotation will indeed be 'screwed up' by pretty-printing the whole project. There are no tools that I know of that can work around that.
A way to get the least amount of history issues is to have each developer prettify a method when he is making changes to it to add functionality or solve a bug, this will take time to propagate the whole code base, but it's the only way I know of.
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
I just had a conversation with my manager relating to checkin\out policies on a project I'm currently working on. Basically I tried to edit a file that was already checked out by another developer and I couldn't - I asked my manager why we couldn't edit the same class at the same time and he gave this reason for turning that functionality off: We had a lot of problems with developers editing the same Form (or anything visual done in the designer) and then cheking it in. Merging the changes in the designer generated code was a lot of hassle...
As I'm writing this I'm struggling to see what problem they were having - surely they were getting the latest code before trying to check something in??
Have any of you come across problems with editing the same Form (or something in the designer) as another developer and then checking into TFS? If so how did your team get around the problem? Did you also turn off the ability for developers to work on the same class?
EDIT: The following post (found here) is exactly the problem my manager was describing. Anyone know of a simpler way to resolve the issue than the ones in that post?
I would argue that the solution to your problem would be to establish best practices for source code modification.
Discourage people from going into UI code and arbitrarily jiggling the components around in the designer. Any reasonable UI modifications should be easily mergeable. Your best bet is to try and educate people as to the best way to merge in any given source control system. Also, as helpful as the designer is, ignorance of what code is being automatically generated in the background will be significantly detrimental in the long-term.
People who insist on locking checked-out files for the reasons you stated in your post typically wait long periods of time to check their code in. Naturally, the more time passes, the more code gets modified, so it makes merging difficult for these people. Checking in early, often, and incrementally requires people to think about their changes in stages, and for some coders, this is a rather painful cultural/psychological adjustment.
I've just checked back through the histories of some of my .designer.cs files and I can't see any changes that would cause a merge problems. There were no wholesale rearrangements of code for example.
Another thing to consider is to make sure that everyone does a "get latest" at regular intervals then any individual merge/resolution isn't going to be that great thus minimising the chances of anything going wrong.
It might also be worth investigating a 3rd party merge tool. There are plenty around.
Now it could be that the changes I've done are simple compared to the ones you've got so you should take my anecdotal data with a pinch of salt.
It can cause problems (in general) when a lot of people are editing UI concurrently. The merge logic will do a fine job merging things, but in a lot of cases the UI is drawn according to how things are added to the form. Your UI can get messed up quickly.
I don't know if I would use this as an excuse to enforce exclusive checkouts across the board, though. I might go from a (non programmatic) policy standpoint that says shared checkout for business logic, but exclusive for UI changes.
I would couple that with a strong MVP, MVC, or MVVM approach, though, which should limit the number of people that have to touch the UI concurrently.
As others have alluded to, keep one of the seminal rules of SCM in mind: merge early and often, and your problems are reduced. (along with that is "always get latest before you start working on the code).
Quite a few people have really taken interest in the dll's ivé sent them, and they're not the type that should be given away for free too often...
I was just wondering, if I were to sell my components, user controls etc, how would I go about protecting them, in terms of ownership/encrypting code (if possible) etc.. What steps have you taken to help prevent people using yours without paying for them?
You can use any commercial obfuscater which encrypt your functionality and giving error if decompile.
Here i have the whole list which are available in market.
I used many of them some are just encrypt string, public method, private methods,properties and all.
Just go through it.
see the whole list and article
The only truly secure way to protect your dll is not to give it to them. Expose it instead via a web-service etc (obviously this doesn't work in all cases). Every obfuscator can be broken with patience. Think how much the games industry spends on this, and things are broken / reverse-engineered within days, sometimes hours.
"Lawyers" may serve as a layer of protection, and obfuscation will certainly discourage idle browsing. But a determined hacker (for example, for commercial illegal spying) will be able to get at your code eventually.
I guess you simply need to weigh the costs and benefits...
Well, I will definitely put my copy right,company name and production name information to my DLL. Whenever anybody use it,those information still appear on my DLL. And if possible,I will try to use Dotfuscator tool from visual Studio which helps to obfuscate my DLL.
i am creating my own CMS frame work, because many of the clients i have, the have same requirements, like news module, newsletter module, etc.
now i am doing it fine, the only thing that is bothering me, is if a client wants to move from my server he would ask me to gibe him his files, and of course if i do so the new person who will take it he will see all my code, use it and benefit from i, and this is so bad for me that i spend all this time on creating my system and any one can easily see the code, plus he will see all the logic for my system, and he can easily know how other clients of mine sites are working, and that is a threat to me, finally i am using third party controls that i have paid for their license, and i don't want him to take it on a golden plate.
now what is the best way to solve this ? i thought it is encrypting, but how can i do that and how efficient is it ?
-should i merge all my CS files and Dlls in bin folder to one Dll and encrypt it, and how can i do that ?
i totally appreciate all the help on this matter as it is really crucial for me.
you should read this
Best .NET obfuscation tools/strategy
How effective is obfuscation?
In my experience, this is rarely worth the effort. Lots of companies who provide libraries like this don't bother obfuscating their code (Telerik, etc).
Especially considering what you are writing (CMSes are everywhere), you'd likely see more benefit from your time spent implementing features that put your product/implementation in a competitive advantage and make companies see that the software you are capable of writing has value, rather than the code itself.
In the end, you want to ensure you are a key factor in making software work for a company, not the DLLs you give them.
You'll need to precompile your site and obfuscate dlls.
Visual Studio has something like Dotfuscator Community Edition shipped with it. You could give it a try.
Of course, HTML output, CSS declarations, database structure and stored procedures code cannot be encrypted.
You can however try to compress CSS which will also reduce its readbility by humans.
Check here: The best approach to scramble CSS definitions to a human-unreadable state throughout an ASP.NET application
One other idea would be to use a frame in your HTML and put the most of the site pages inside of it. This way, it will not be visible when doing "View source".
Or just state it clearly that you offer whatever you're doing as a service and do not provide source codes of your work. I somehow doubt salesforce would be willing to give their sources to anyone who asks.