Develop Reference

C# Hide external dlls [duplicate]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I release a bunch of tools for free, but recently I have began to sell an application, that has private research, and people have been able to get my source code, and one person publically released my entire source. I spent a lot of time on this program, just to have someone crack it, and release my entire source.
How can I go about protecting my program? I have tried HWID, but people are still able to crack it. I know I am limited by C#, but it the most convenient to use. I just need a way to protect my programs from people trying to do this.

You could have a look at the many obfuscation tools that are out there, for example these:
http://gapotchenko.com/eazfuscator.net
http://orangeheap.blogspot.nl
http://confuser.codeplex.com (succeeded by https://yck1509.github.io/ConfuserEx/ and then again by https://github.com/XenocodeRCE/neo-ConfuserEx)
http://ntoolbox.com)

Well, the problem with languages like C#/Java is that they are generally much easier to de-obfuscate. The way to secure this is generally to put this stuff into a webservice, but you said you couldn't really do that. What about porting specific non-trivial functions over to a language like C, and obfuscate that. Your C# program could then use reflection to make calls to this external/unmanaged dll. It would increase the difficulty for de-obfuscating, but the problem is that if someone wants it bad enough, they can figure it out as it is client-side.
It may be that legal action is the only real solution here, but this is not a site for legal advice, and I am not qualified to give it if it were.
Additionally, this could be a business decision. Consider Making your software open-source and post a donation link. I am also not qualified to give business advice, but this is worth considering. It may actually increase your revenue, not to mention the other benefits that come with releasing open-source software.

There's Dotfuscator (http://www.preemptive.com/products/dotfuscator/overview). But the best solution in some cases is to offer what you do as a web site (Software as a Service).
Consider this tool for example to convert VB to C#: http://converter.telerik.com/
Or this tool to format JSON: http://jsonformatter.curiousconcept.com/
This may or may not work for you. I don't know what the nature of the software you're trying to protect is.

No, your code needs to contain the information needed to decrypt itself, its an impossible problem to solve.
Your best solution is to put your intellectual property on a server in the cloud that only you have access to. Give your customers a unique login, audit their access to check for abuse, off load as much grunt work onto your customers machines, but keep your algorithms locked into the cloud.

Best Practices for improving Software Quality [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
We are looking for methods to improve our internal processes when developing software.
We have already adopted TDD contiguous integration and Agile. Any obscure features of visual studio or TFS?
All suggestions welcome.

I don't think there can be a magic bullet. Beauty (or in this case quality) is in the eye of the beholder.
With that said, I can give you some suggestions as to some of the ways we ensure code quality.
One suggestion can be to include Code Coverage into your assessment of Software Quality. It is one thing to have unittests written for your code, but code coverage helps you identify what code is actually 'covered' by a test, which can sometimes identify use-cases/scenarios that you may not have considered. I recommend you investigate nCover.
You may also wish to dig deeper and look into using nDepend...
NDepend is a tool that simplifies
managing a complex .NET code base.
Architects and developers can analyze
code structure, specify design rules,
plan massive refactoring, do effective
code reviews and master evolution by
comparing different versions of the
code.
I appreciate that these are not TFS features but you can easily 'integrate' them into your visual studio environment using TestDriven.NET
This is of course not an exhaustive list of things - you need to find what suits you and gives you the confidence about your code's quality.
Hope this helps,

Here's a helpful list: http://www.joelonsoftware.com/articles/fog0000000043.html ("The Joel Test: 12 Steps to Better Code" by Joel Spolsky)

If you really don't have anything to do, and you have the resources you can try code review. This procedure includes double checking the code before every (real) commit. This helps to catch bugs early in the development process. Google is using this technique widely.
Sadly the tools supporting these kind of procedures are pretty basic and hard to use currently. If you do a googling on you'll find one or two simple code review tool for TFS.
Be careful though. These techniques doesn't help you make good software alone. You still need a good architecture, quality code, etc. (Okay, TDD helps code quality, but architecture is still a gray area.) I'm not aware of any techniques that help that currently and doesn't hurt the development process too much. You have to wait till Visual Studio 2010 comes out with all the bling-bling of model validation, automatic uml diagram generation, etc.

Personally I believe in code reviews. Some of advantages are:
Constantly keeping an eye on code quality and coding standards.
It's easy to notice any unusual/buggy/hard to understand coding structures (i.e. long if conditions, strange type conversions, etc.).
While reading someone else code it's easier to notice all false assumptions (could be negative false) (i.e. this object is never null), which could introduce bugs.
It makes familiar with all changes to source code, so it's easy to remember that this piece of code was lastly modified (which could introduce bugs).
It makes easy to learn (and teach) good habits.
And I do not believe in any tools, which are thread as special kind of silver bullet -- which is not true.

read: Code Complete

It is good that you have implemented TDD, CI and Agile. Just having ANY process is far better than many places I have seen. Code reviews are probably the single best way to disseminate knowledge and flesh out defects early.
For my money, though, stick to the basics. If you are not doing requirements management, you should consider it. You should know what your customer requirements are when you start your sprint or development cycle. Conduct a review of those and discover your derived requirements, if any. Lastly, you should come up with a way to verify that 1) you built everything you intended 2) you tested everything the customer asked for. There are processes to do this but if you can find a way that's good for you, do it!
RM takes less time than code reviews and catches the "really big" mistakes.

You are probably the most happiest guys if you have already adopted TDD, CI and Agile and have nothing to do =) I think you have a very big field of process improvement with TDD and Agile practices.

What advantages are to be had by using Java+Swing over C#+WinForms/WPF? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
There is a group here using Java, server-side and client-side, with Swing for the client UIs. I plan to suggest that they change the front end to C# and WinForms or WPF, but I want to come prepared with:
A list of benefits to be had from moving to Winforms / WPF from Swing.
A list of Swing benefits that might get thrown back at me over using WinForms / WPF (the only one I can think of off the top of my head is the ability to share more code across server and client due to being the same language - given the fact that the server side will stay Java).

I'll preface this by saying I'm a .net developer so the following might be heretical.
It sounds like your company already has a significant investment in java. People, software licenses, and code base.
If my company (or group) was primarily java and we were successful in meeting business demands, then quite frankly there would be no way I'd switch.
The only way I'd consider switching technology stacks is if the stack we were on was truly dead. Meaning that it was very difficult to find programmers for, it could no longer meet business needs, we had a high number of failed projects, and/or the language itself was no longer evolving.
Switching just because someone prefers one language over another is non-starter and ultimately wouldn't make any business sense. The very act of a change like that will mean that the company is going to lose those people who are still committed to the old stack. Replacing people is extremely expensive just in terms of knowledge lost.
Another thing, if you don't already know what the hard reasons are for switching platforms then you shouldn't even try to encourage it. Take the accountants point of view, what really would this provide?

1) Swing stinks. (Almost just kidding, but really, in my opinion, it's pretty awful.) Even if you're going to develop in Java, use SWT or some other decent looking/behaving toolkit. Moving to Windows Forms or WPF will (potentially) give you a lot more powerful user interface options on Windows, but only on Windows.
2) You're tying yourself to Windows, and losing the cross platform nature of Java+Swing. You're potentially losing some ability for shared code. You're having to redevelop in non-java, which may mean a lack of experience/training/knowledge on the part of other developers on your team.

Performace & startup time. You just can't compare Swing to Winforms/WPF in the performace/startup time aspect.
Really don't know... if you have a high qualified Java team that does not know .Net APIs, stick to Swing, otherwise, don't think twice... Use Winforms. About "the ability to share more code across server and client due to being the same language", don't bother... there is zillions of ways to make two different applications from different languages that each other.

The performance of the GUI should be faster with a .NET winform app compared to a Swing app running on Windows. It's not really a huge difference at this point for most apps though, computers these days can run Java pretty fast.
Either way you would still be talking to the Java backend code. Depending on what they've done you may be better off just sticking with the Swing front end.
If it's an option you should think about a web front end. If it can be made in XHTML/Javascript/CSS, you would retain the cross platform benefits that the Java GUI gives you.
But really, you need to think about why you want to change to Winforms instead of Java. Is there something about the existing Java app that you don't like that would be better and worth the cost of redeveloping in another language? Is it something that can be fixed without a full rewrite?

Do you have any custom components which would be a pain to migrate from Swing to .net? Do you have staff that are expert at developing custom Swing components (Java2D expertise, familiarity with Swings input subsystem etc.) who know little about WinForm custom development?
If the answer either to these questions is yes then you should probably stick with Swing.

1) It is easier to make a Winforms app feel like a Windows app. Java applications usually feel "funny" if you aren't careful.
2) Everything you are programming is using Java. Having one component that is not Java means that the project is harder to work with. Overall maintenance will also be more annoying. Currently, everyone on your project team needs to know Java only in order to be able to work with anyone else on your project team. From a recruiting and maintainability perspective, this is convenient. Personally, I be against switching the GUI unless you were getting some other benefit out of it.
You have not provided any reasons why you plan to make your proposal.

If using windows .net is the better choice because yo have:
1. Good designer in Visual studio, good documentation and examples
2. Better startup, CPU and memory usage at runtime: see http://www.codeproject.com/KB/dotnet/RuntimePerformance.aspx
If using Linux, you have Mono versus Java, but it is more complicated to make a comparison there due to the large number of distros.

The big advantage are free libraries you can use in java.Most of the nosql systems are written in java , the best of all Neo4j (only java will give you ability to run these products embedded). This is something dot net can't do, and these will give your applications ability no winforms, wpf can have.

Ever done a total rewrite of a large C++ application in C#? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I know Joel says to never do it, and I agree with this in most cases. I do think there are cases where it is justified.
We have a large C++ application (around 250,000 total lines of code) that uses a MFC front end and a Windows service as the core components. We are thinking about moving the project to C#.
The reasons we are thinking about rewriting are:
Faster development time
Use of WCF and other .NET built-in features
More consistent operation on various
systems
Easier 64 bit support
Many nice .NET libraries and
components out there
Has anyone done a rewrite like this? Was it successful?
EDIT:
The project is almost 10 years old now, and we are getting to the point that adding new features we want would be writing significant functionality that .NET already has built-in.

Have you thought about instead of re writing from scratch you should start to separate out the GUI and back end layer if it is not already, then you can start to write pieces of it in C#.
the 250,000 lines were not written overnight they contains hundreds of thousands of man years of effort, so nobody sane enough would suggest to rewrite it all from scratch all at once.
The best approach if you guys are intend on doing it is piece by piece. otherwise ask for several years of development effort from your management while no new features are implemented in your existing product (basically stagnating in front of competition)

My company actually did that. We had a C++ code base of roughly that size, and everybody (programmers, management, customers) more or less agreed that it wasn't the best piece of software. We wanted some features that would have been extremely hard to implement in the old code base, so we decided (after many discussions and test projects) to rewrite it in .NET. We reused the code that was modular enough using C++/CLI (about 20% of it - mostly performance-critical number-crunching stuff that should have been written in C++ anyway), but the rest was re-written from scratch. It took about 2 man-years, but that number really depends a lot on the kind of application, the size of your team and on your programmers, of course. I would consider the whole thing a success: We were able to re-architect the whole system to enable new features that would have been near-impossible with the old code base. We also could avoid problems we often had in the old software by re-designing around them. Also, the new system is much more flexible and modular in the places where we learned that flexibility was needed. (Actually I'm sometimes surprised at how easily new features can be incorporated into the new system even though we never though of them when we designed it.)
So in a nutshell: For a medium-sized project (100k-500kloc) a rewrite is an option, but you should definitely be aware of the price and risk your taking. I would only do it if the old codebase is really low-quality and resists refactoring.
Also, there's two mistakes you shouldn't do:
Hire a new .NET programmer and let him/her do the rewrite - someone new can help, but most of the work and especially the design has to be done by developers who have enough experience with the old code, so they have a solid understanding of the requirements. Otherwise, you'll just repeat your old mistakes (plus a couple of new ones) in a different language.
Let a C++ programmer do the rewrite as their first C# project. That's a recipe for disaster, for obvious reasons. When you tackle a project of that size, you must have a solid understanding of the framework you're using.
(I think these two mistakes might reasons why so many rewrites fail.)

Its been tried before, not only C++ => C#, but VB6 => VB.NET, C++ => Java and any other old => new that you can think of. it never really worked. I think that because ppl don't consider that transformation for what it really is (a total rewrite) they tend to take it lightly.
The migration story from C++ => .NET should be thru CLI, carefully deciding what managed and whats remains unmanaged and s-l-o-w-l-y "fixing" piece by piece.

Expression Blend was originally an MFC app. The current version uses WPF for the UI but the engine is still all native. I saw a great talk by principal architect Henry Sowizral about a year ago where he described the process of the migration. Make the engine UI agnostic and you will be able to support whatever the latest UI technology is. The Expression team at one point had what he referred to as the hydra-headed version. Two front-end UIs running simultaneously with one underlying engine - in this way they could see where behavior had unintentionally deviated from the previous version. Since the UI subscribed to events and notifications, changes made in a WPF toolwindow were reflected in the old MFC toolwindow.
EDIT: Looks like some powerpoints are available here or as html here.

I've been through a project that did exactly what you're describing with approximately the same size codebase. Initially, I was completely onboard with the rewrite. It ended up taking 3+ years and nearly turned into a death march. In general, I now agree far more with the incrementalists.
Based on our experience, though, I will say that such a rewrite (especially if you're able to reuse some C++ business logic code in .NET), is not as technically dangerous as it may seem. However, it can be very socially dangerous!
First, you have to make sure that everyone fully understands that what you are undertaking initially is a "rewrite" (or "remake") not an upgrade or "reimagining." The 1998 Psycho was a shot-for-shot remake of the 1960 original. The 2003 Battlestar Galactica was a reimagining of the 1978 original. See the difference?
In our case, the initial plan was to recreate the existing product in .NET. That would not have been technically daunting, since we understood the original well. However, in practice, the urge to add and fix and improve just a few things proved irresistible, and ultimately added 2-3 years to the timeline.
Second, you have to make sure that everyone from the execs to sales staff to the end users is ok with your current product remaining unchanged during the development of the remake. If your market is moving is such a way that you won't be able to sustain your business during that period, then don't do it.
So the main obstacles for us turned out to be social, rather than technical. Users and business interests became very frustrated with the lack of visible progress. Everyone felt compelled to push for their own pet improvements and features, too, so our final product bore only a superficial resemblance to the original. It was definitely a reimagining rather than a remake.
In the end it seems to have turned out ok for us, but it was a real grind, and not something we'd choose to do again. We burned through a lot of goodwill and patience (both internal and external), which could've largely been avoided with an incremental approach.

C++ won't automatically translate to C# (not so you'd want to maintain it, anyway), and you're talking about using different frameworks.
That means you're doing a total rewrite of 250K lines of code. This is effectively the same as a new 250K-line project, except that you've got the requirements nicely spec'd out to start with. Well, not "nicely"; there's doubtless some difficult-to-understand code in there, some likely because of important issues that made elegance difficult, and the overall structure will be somewhat obscured.
That's a very large project. At the end, what you'll have is code that does the same thing, likely with more bugs, probably fairly badly structured (although you can refactor that over time), with more potential for future development. It won't have any of the new features people have been asking for during the project (unless you like living dangerously).
I'm not saying not to do it. I'm saying that you should know what you're proposing, what the cost will be, and what the benefits would be. In most cases, this adds up to "Don't do that!"

I did something similar. Part of my job involves developing & supporting some software called ContractEdge. It was originally developed in Visual C++ 6 by a team in India. Then I took over the development role after it was basically done in 2004. Later on, when Windows Vista was made available as a Beta I discovered that ContractEdge would crash in Vista. The same thing happened in the release candidate.
So I was faced with a decision. Either hunt for the problem in tens of thousands of lines of mostly unfamiliar code, or take the opportunity to rewrite it in .NET. Well, I rewrote it in VB.NET 2.0 in about 2 months. I approached it as a total rewrite, essentially scrapping everything and I simply focused on duplicating the functionality with a different language. As it turns out I only had to write about 1/10th the number of lines of code as the original. Then we held a one month long beta program to iron out any remaining bugs. Immediately after that we launched it and it's been a big success ever since, with fewer problems than the C++ version it replaced.
In our particular scenario I think the rewrite worked out well. The decision was made easier based on the fact that nobody on our team was as familiar with C++ as they were with .NET. So from that perspective, maintainability is now far easier. Nowadays I do think C++ is too low-level of a language for most business software. You really can get a lot more done in .NET with less code. I wrote about this subject on my blog.

Total rewrite for the sake of rewrite? I would not recommend it.

In addition to other responses, I would not take "faster development time" for granted. Sure, for most "business" data-centric applications it will probably be the case, but there are many areas where .NET will not bring in significant productivity increases, plus you need to take the learning curve into account.

We've done a big C++ >> C# migration as we move to .NET. It's a quite tough project. Management would hardly bite the funding for it, so you have to go for a compromise. Best approach is to leave the innermost (or lowest) layers in C++ and cover the upper part with C#, with better APIs designed with newer concepts like readability and API-usability in mind, safe-guarded with unit tests and advanced tools like FxCop. These are obviously great wins.
It also helps you layer your components a bit better as it forces certain cuts. The end product is not nice as you might end up copying a lot of code in C++ because years and years of coding contains many bug fixes and many undocumented and hard-to-understand optimizations. Add to that all the pointer tricks you could do in C (our code has evolved from C into C++ over time). As you stabilize you find yourself more and more reading the C++ code and moving it into the C# - as opposed to 'cleaner design' goals you had in mind in the beginning.
Then you find out that interop performance sucks. That may call for a second rewrite - maybe use unsafe C# code now. Grrr!
If all the team members come from C++, the new code is also look like a C++ design. Try to go for a mix of C# and C++ developers in the team, so you can get a more .NET-alike API at the end.
After a while, the project may lose interest and mgmt may not fund the entire re-write so you end up getting a C#-sugarcoated C++ code, and you may still have unicode/64-bit issues unresolved. It really calls for a very very careful planning.

I was involved in a very similar size project. It was necessary to rewrite the GUI front end because of new hardware and new requirements. We decided to port this to .NET using C++/CLI. We were able to reuse more then halve of the code and porting it work quite well.
We were able to take advantage of .NET where it made the most sense. This made major parts of the code much cleaner. We found the book "Pro Visual C++/CLI and the .NET 2.0 platform" by Stephen R. G. Fraser very helpful.

Have you considered a port to C++.NET? It might be less painful.

I'm currently rewriting a rather large web application.
One thing to remember is that when converting from one language to another especially something like C++ to .Net is that you may end up with less, and probably cleaner, code due either due to language advances or framework code.
That's one advantage for future maintainability, even aside from the opportunity to re-architect the less robust aspects of the old application.

Some additional comments.
Depending on the lifespan of your application you may be forced to rewrite it in a modern language since I suspect that C++ developers will become increasingly hard to find.
Just moving the app to a new language will not reap that great rewards. You'll probably want to do a redesign of the app as well! Do not underestimate the effort required to do this. I would guess the effort for a redesign + rewrite could be as much as 50% of the effort for the original implementation. (Of course, 50% is a totally unscientific guess).
It's way to easy fool yourself into thinking "Well, C# and WPF are just so much more productive that rewriting this mess would be a piece of cake!"

Interestingly most of the answers from people who have done this seem positive. The most important thing IMO is to have good unit tests so that you can be sure your rewrite does what you want it to do (which may not be exactly the same as what the old code did).

Should you obfuscate a commercial .Net application?

I was thinking about obfuscating a commercial .Net application. But is it really worth the effort to select, buy and use such a tool? Are the obfuscated binaries really safe from reverse engineering?

You may not have to buy a tool - Visual Studio.NET comes with a community version of Dotfuscator. Other free obfuscation tools are listed here, and they may meet your needs.
It's possible that the obfuscated binaries aren't safe from reverse engineering, just like it's possible that your bike lock might be breakable/pickable. However, it's often the case that a small inconvenience is enough to deter would be code/bicycle thieves.
Also, if ever it comes time to assert your rights to a piece of code in court, having been seen to make an effort to protect it (by obfuscating it) may give you extra points. :-)
You do have to consider the downsides, though - it can be more difficult to use reflection with obfuscated code, and if you're using something like log4net to generate parts of log lines based on the name of the class involved, these messages can become much more difficult to interpret.

Remember that obfuscation is only a barrier to the casual examiner of your code. If someone is serious about figuring out what you wrote, you will have a very hard time stopping them.
If you have secrets in your code (like passwords), you're doing it wrong.
If you worried someone might produce your own software with your ideas, you'll have more luck in the marketplace by providing new versions that your customers want, with technical support, and by being a partner to them. Good business wins.

At our company we evaluated several different obfuscation technologies, but they all had problems. The biggest problem was that we rely a lot on reflection, e.g. to dynamically create grids based upon property names.
So all of the obfuscators rename things, you can disable it of course, but then you lose a lot of the benefit of obfuscation.
Also, in our code we have a lot of NUnit tests which rely on a lot more of the methods and properties being public, this prevented some of the obfuscators from being able to obfuscate those classes.
In the end we settled on a product called .NET Reactor
It works very well, and we don't have any of the problems associated with the other products.
"In contrast to obfuscators .NET Reactor completely stops any decompiling by mixing any pure .NET assembly (written in C#, VB.NET, Delphi.NET, J#, MSIL...) with native machine code. In detail, .NET Reactor builds a native wall between potential hackers and your .NET code. The result is a standard Windows based, not MSIL compatible, file. The original .NET code remains intact, well protected by native code and invisible for prying eyes. The original .NET code is not copied on harddisk at any time. There is no tool which is able to decompile .NET Reactor protected assemblies."

The fact that you actually can reverse engineer it does not make obfuscation useless. It does raise the bar significantly.
An unobfuscated .NET assembly will show you all the source, highlighted and all just by downloading the .NET Reflector. Add obfuscation to that and you'll reduce very significatively the amount of people who'll be able to modify the code.
It depends on you are you protecting yourself from. If you'll ship it unobfuscated, you might as well open source the application and benefit from marketing. Shipping it obfuscated will only allow people to relatively easily generate modified binaries through patches instead of being able to steal your code and create a direct competitor. Getting the actual source from obfuscated code is very hard, depending on the obfuscator, of course.

I think that it depends on the type of your product. If it is directed to be used by developers - obfuscation will hurt your customers. We've been using the ArcGIS products at work, and all the DLLs are obfuscated. It's making our job a lot harder, since we can't use Reflector to decipher weird behaviors. And we're buying customers who paid thousands of dollars for the product.
So please, don't obfuscate unless you really have to.

Things you should take into account:
Obfuscation does not protect your code or logic. It just makes it harder to read and understand.
Obfuscation does no one stop from reverse engineering. It just slows the process down.
Your intellectual property is protected by law in most countries. So if an competitor uses your code or specific implementation, you can sue him.
The one and only problem obfuscation can solve is that someone creates a 1:1 (or close to 1:1) copy of your specific implementation.
Also in an ideal world reverse engineering of an obfuscated application is economical unattractive.
But back to reality:
There exists no tool on this planet that stops someone from copying user interfaces, behaviors or results any application provide or produce. Obfuscation is in this situations 100% useless
The best obfuscator on the market cannot stop one from using some kind of disassembler or hex editor and for some geeks this is pretty good to look into the heart of an application. It's just harder than on an unobfuscated code.
So the reality is that you can make it harder and more time consuming to look into your application but you won't really get any reliable protection. Regardless if you use a free or an commercial product.
Advanced technologies like control flow obfuscation or code virtualization may help to make understanding of logic sometimes really hard but they can also cause a lot of funny and hard to debug or solve problems. So they are sometimes more like an additional problem than a solution.
From my point of view obfuscation is not worth the money some companies charge for their products. If you want to nag casual developers, open source obfuscators are good enough. If you want to make it as hard as possible to look into the heart of your applications, you need to use cryptographic containers with virtual execution environments and virtual filesystems but they also provide attack vectors and may also be a source for a bag full of problems.
Your intellectual property and your products are in most countries protected by law. So if there's one competitor analyzing and copying your code, you can sue him. If a bad guy or and hacker or cracker takes your application you are pranked - but an obfuscator does not make a difference.
So you should first think about your targets, your market and what you want to achieve with an obfuscator. As you can read here (and at other places) obfuscation does not really solve the problem of reverse engineering. It only makes it harder and more time consuming. But if this is what you want, you may have a look to open source obfuscators like e.g. sharpObfuscator or obfuscar which may be good enough to nag casual coders (a List can be found here: List of .NET Obfuscators on Wikipedia).
If it is possible in your scenario you might also be interested in SaaS-Concepts. This means that you provide access to your software but not the software itself. So the customer normally has no access to your assemblies. But depending on service level, security and user base it can be expensive, complex and difficult to realize a reliable, confident and performant SaaS-Service.

No, obfuscation has been proven that it does not prevent someone from being able to decipher the compiled code. It makes it more difficult to do so but not impossible.

I am very confortable reading x86 assembly code, what about people that is working with assembly for more than 20 years ?
You will always find someone that only need a minute to see what your c# or c code is doing...

Just a note to anyone else reading this years later - I just skimmed through the Dotfuscator Community Edition (that comes with VS2008) license a few hours ago, and I believe that you cannot use this version to distribute a commercial product, or to obfuscate code from a project that involves any developers other than yourself. So for commercial app developers, it's really just a trial version.

...snip...
these messages can become much more
difficult to interpret
Yes, but the free community edition that comes with Visual Studio has a map functionality.
With that you can back track the obfuscated method names to the original names.

I've had success putting the output from one free obfuscator into a different obfuscator. In Dotfuscator CE, only some of the obfuscation tricks are included, so using a second obfuscator that has different tricks makes it more obfuscated.

It's quite simple to reverse engineer a .net app using .net reflector - since the app will generate VB, VC and C# code straight from the MSIL, and it's possible to pull out all kinds of useful gems.
Code obfuscators hide code quite well from most reverse engineering hacks, and would be a good idea to use on proprietary and competitive code that adds value to your app.
There's a pretty good article on obfuscation and it's workings here

This post and the surrounding question have some discussion which might be of value. It isn't a yes-or-no issue.

Yes you definitely should. Not to protect it from a determined person, but to get some profit and have customers. By the way, if you reach a point here someone tries to crack your software, that means you sell a popular software.
The problem is what tool to choose for the job. Check out my experience with commercial obfuscators: https://stackoverflow.com/questions/337134/what-is-the-best-net-obfuscator-on-the-market/2356575#2356575

Yes, we do. We use BitHelmet obfuscator. It's new, but it works really well.

But is it really worth the effort to select, buy and use such a tool?
I found Eazfuscator cheap (free), and easy to use: took about a day.
I already had extensive automated tests (good coverage), so I reckon I could find any bugs that are/were introduced by obfuscation.