I am using a huge open source library in C#, but I'm only using it for a handful of specific functions. Is there a tool that I can use to automatically clean out all unused code?
I tried going about it manually using resharper but the code is so deeply nested that it is impossible...
Try something like this: include a project containing code that calls the methods you need. Maybe this should be a unit test project. Use solution-wide analysis to remove code that is completely unused.
Then start making the public classes private. Revert this as soon as you "see red".
Also be sure to remove unused references.
If you have Ultimate, you can use a dependency diagram to give you. Visual clue about what's not used.
As far as I know there is no simple way to do this. In order to isolate specific methods you'll need to understand all of their dependencies and make sure those remain intact. From what you've said - which isn't enough for me to really know, this is pure speculation - you're going to have to take a lot or take nothing at all.
As recommended by DJ KRAZE, if you really only want a small subset of the functionality, make it yourself.
Related
I am working on a C# project and have two programmers to help me on parts of the project. The problem is that I don't trust these programmers as they are joining recently and need to protect my company's property.
I need to hide some parts of the code from the two programmers so they don't see it and they should still be able to work on their parts and run the full application to test it.
Is there such thing ? :)
Know a few things:
You Can't Hide Code Users Compile Against.
C# makes it incredibly easy to see what you're compiling against, but this is actually true for all programming languages: if they are required to compile it, compile against a dll, or they can run it, either as a DLL or as raw C#, they can get access to the logic behind it. There's no way around that. If the computer can run the program and it all resides on your PC, then the human can look it over and learn how to do it too.
HOWEVER! You can design your program in such a way that they don't need to compile against it.
Use Interfaces.
Make the code that the other employees must write a plug-in. Have them write their code as an entirely separate project to an interface that the core part of your API loads dynamically at run time.
Take a look at The Managed Extensibility Framework for a tool to do this.
Use Web or Remote Services.
Components of particular secrecy can be abstracted away so the details of how it works can be hidden and then invoked via a web call. This only works in situations where the core details you want to protect are not time sensitive. This also doesn't protect the idea behind the feature: the employee will need to understand it's purpose to be able to use it, and that alone is enough to rebuild it from scratch.
Build Trust Through Code Reviews.
If you don't currently trust your employees, you need to develop it. You will not be able to know everything that everyone does always. This is a key skill in not just programming, but life. If you feel that you can't ever trust them, then you either need to hire new employees that you can trust, or build trust in them.
One way to build trust in their capabilities is through code reviews. First, make sure you're using a version control system that allows for easy branching. If you aren't, switch immediately to Mercurial*. Have an "integration" area and individual development areas, usually through cloned branches or named branches. Before they commit code, get together with the employee and review the changes. If you're happy with them, then have them commit it. This will consume a little bit of time on each commit, but if you do quick iterations on changes, then the reviews will also be quick.
Build Trust Through Camaraderie.
If you don't trust your employees, chances are they won't trust you either. Mutual distrust will not breed loyalty. Without loyalty, you have no protection. If they have access to your repository, and you don't trust them, there's a good chance they can get at the code you want anyway with a little bit of effort.
Most people are honest most of the time. Work with them. Learn about them. If one turns out to be working for a hostile entity, they've probably already obtained what they wanted to get and you're screwed anyway. If one turns out to be a pathological liar or incompetent, replace them immediately. Neither of these issues will be saved by "protecting" your code from their eyes.
Perform Background Checks.
A further way to improve trust in your employee, from a security standpoint, is a background check. A couple hundred bucks and a few days, and you can find out all sorts of information about them. If you're ready to hide code from them, and you're the employer, you might as well do due diligence before they steal the secrets to the universe.
Your Code is Not That Important.
I hate to break it to you, but there's almost a 100% chance that your code is not special. Trying to protect it through obscurity is a waste of time and a known, poor, protection method.
Good luck!
**Why Mercurial? Just because it's one option that's easy to get started with. Feel free to use any other, like Git, if it suits your fancy. Which one you use is entirely besides the point and irrelevant to this overall discussion.*
You can't do it,
Even if you only give them a DLL with your code, they can extract the code with reflection tools, e.g. reflector.
Keep a separate backup and submit dummy placeholders to source control.
The complicated way: set up an application server with VS2010 and all the files they need, lock everything down so they cannot access any files directly and can only run VS2010 and the built application, and provide only DLLs for the protected code.
Theoretically, they would be able to work on the code they need to but would never have direct access to the DLLs, nor would they have the ability to install or use a tool such as .NET Reflector to disassemble the files... might still be some holes you'd need to look for though.
The right way: Hire trustworthy programmers. ;)
Put your code into a DLL and use Dotfuscator to obfuscate the internal workings.
The only way I can see is to give them compiled and obfuscated assemblies to reference. Because you can only obfuscate private members you may possibly need to modify your code so that public methods do not do much if anything at all. If there is any interesting code in a public method you should rearrange your code like this:
public bool ProcessSomething()
{
return this.DoProcessSomething();
}
private bool DoProcessSomething()
{
// your code
}
Even obfuscator that comes free with VS will do some job to make it non-trivial to look into your code. If you require more protection you need better obfuscator of course.
But in the long run it is impractical and sends bad signals to those developers telling that you do not trust them. There can be nothing good coming out of this. If you're not the boss (or owner of the code) I would not worry that much - after all it's not your property. You can talk to your boss to express your concerns. If you are the boss you should have not employed people you do not trust in the first place.
What do you think about renaming all my classes, properties, methods, etc to stuff like _, __ or ___? How close would this be to what a C# obfuscator (like Dotfuscator or Eazfuscator) would do to my app, and, what else could I manually do (on a reasonable amount of time) to make my code as obfuscated as possible? The reason why I want to do this is because an obfuscator will mess up my data binding and because they don't obfuscate apps published with ClickOnce (unless I do some expert stuff with manifests and other stuff that I don't know how to do and that nobody seems to really know for sure if it always work).
You should obfuscate your application. To avoid any data binding errors a number of Obfuscators now provide silverlight / wpf obfuscation defaults that will help you avoid those errors.
After obfuscation you can make a clickonce installer using mage.exe
http://msdn.microsoft.com/en-us/library/xc3tc5xx.aspx
Seriously DO NOT do the renaming. You are making your life more difficult. In fact as difficult as they guy you don't want stealing your code.
Its just one bat file to make the clickonce after a build.
Here's an odd idea for you. I assume your development environment supports refactoring, and renaming variables is certainly a popular refactoring operation. See whether you can script that. If you can't, consider something like AutoIt. See where this is headed? Express your renaming in term of refactoring operations, script them and make this into a pre-compile step.
That way you can keep your sources unobfuscated, yet do all the obfuscation operations that you want, and that you know will work.
The reason why I want to do this is because an obfuscator will mess up my data binding
I don't know how your data-binding works, but if you're hard-coding property names as string in your C# source-code then I'd replace the hard-coded strings with lamdas to identify the property. This is more refactoring friendly too.
Get property name inside setter
Is it absolutely necessary to support ClickOnce? There are other ways to distribute an application. Consider compiling the code, using the obfuscator of your choice, and then building an installer using something like Inno Setup.
I strongly recommend you do not rename stuff in the code directly. If you must follow this path, try making a copy of the project (once in its final state), opening the copy in your IDE, and using refactoring tools to rename classes, variables, and methods. If you do not make a copy, your code will be very difficult to change later.
The free version of Babel.NET worked pretty well for me, it obfuscated the internal code of the functions and renamed all the private and internal classes and members. We use reflection, serialization and data binding and it didn't mess with any of those.
It also supports integration with MSBuild which I believe would help to deal with the posterior ClickOnce generation.
Having just gone through a small experimenting session to try to see how much work it would take to bring our .NET class library, or at least portions of it, into Silverlight so that we can reuse business logic between the two worlds, I'm wondering if others have experience with this sort of thing.
The things I noticed, off the top of my head:
Lots of attributes missing (Browsable(false) for instance)
Lots of interfaces missing, or present, but empty (ICloneable is hidden, ITypedList missing)
Reflection differences (everything reachable needs to be public)
Some base class differences (no Component?)
So I'm wondering, is it really feasible for me to even look at this as a possibility?
I got the initial code running, but I had to just comment out a whole lot of the base functionality, mostly around handling lists since they are based on ITypedList and some base classes. Apparently I need to change to ObservableCollection in Silverlight, so a whole of of base-code needs to be changed in order to cope.
The actual business test class I created is 99.5% identical to the one I would've made for .NET, only some minor changes that would easily be usable in .NET as well, just not as I would've made it before looking at Silverlight. In other words, it looks feasible to share business logic, provided I can make the base classes compatible.
Just so I'm clear, what I'm talking about is that I would basically have two project files, one for .NET, and one for Silverlight, but the actual C# source code would be the same, shared between the two.
So does anyone have any experience with this? Any tips or guidelines?
Will it be worth it? It certainly warrants more looking into.
It is definitely feasible.
It's done on a project here; the Silverlight project includes the C# ones, and there are some #IF statements handling some things (like log4net declarations), and other times things are just re-implemented. But in general, it's a huge win, and you should definitely attempt it (and certainly, we have, successfully).
-- Edit:
One point though, is that our OR/M (LLBLGen) didn't have inbuilt support for 'simple' objects to send down through Silverlight; but someone had written a plugin that handled it, which helped. So it may be worth considering what sort of DAL you're using, and how well it supports Silverlight.
What I've done to facilitate this is:
Frequent use of partial classes and #if !SILVERLIGHT to separate code into parts that Silverlight can handle.
Use of code generation whenever possible. For example I've been experimenting with T4 templates that generate Silverlight equivalent attributes (DisplayAttribute instead of DescriptionAttribute for example)
Whenever there's an interface/attribute that isn't implemented by Silverlight (such as IDeserializationCallback, ICloneable, INotifyPropertyChanging) I will create a dummy interface of the same name in the Silverlight application as long as I know that the fact that the implementation won't be used is not a problem.
Finally, it's worth noting that in Silverlight 4, the assembly format does allow for sharing of binaries between Silverlight and .NET as long as there are no dependencies that Silverlight does not support.
One more note about the separate base classes - it may be worthwhile to create an abstract class that derives from ObservableCollection in Silverlight and BindingList (or whatever you're using in .NET) to minimize the impact on your typed collections.
UPDATE
Today I was working on porting some .NET code to Silverlight that made heavy use of the System.Diagnostics API's like TraceSource, SourceSwitch, etc which do not exist in Silverlight. I created very minimal implementations of these in the Silverlight project and put them in the Einstein.Diagnostics namespace. In doing so I decided I needed a convention to easily identify code that was mimicking the .NET Framework vs. my own code. So I renamed the placeholder files to prefix them with an # sign. I also prefixed the class names in those files as well. The nice thing about that is that the # sign does not actually change their class names as far as the C# compiler is concerned. So #SourceSwitch still compiles to be Einstein.Diagnostics.SourceSwitch but in the code I can easily see something is up. I've also decorated these classes with a [SilverlightPlaceholder] attribute.
I do this with protobuf-net, and I use a few approaches:
conditional compilation symbols in the project file to trigger subtle code-branches (yes, it isn't perfect, but it works)
re-introduction of some things; attributes might be an example here - your code can still use re-introduced attributes, even if the framework code doesn't; as a more extreme example of this, for compact framework I had to re-introduce a good chunk of the Expression API, which was fun
just drop some things ;-p
However if you are using ITypedList (which you mention), I can see that whole approach falling apart pretty messily; component-model is complex enough already, without having to force your way through the hacks too. It really depends quite how far you've gone down this road. Maybe 4.0 / dynamic will open up some of these options again?
One possible fix to your issue is to copy the missing code from the Mono project. Back in the day, I did a small project with the Compact Framework and it was missing the entire System.XLM namespace. I just copied the entire thing from Mono into my project, compiled it and it worked great with minimal changes, iirc.
Are there any tools that can find any private functions without any references? (Redundant functions)
Reason being, that a function may have been created and called from a couple of areas, but as the project expands and grows, these two calls may have been removed and swapped with a better alternative. But the method may still remain. I was wondering if there were any handy tools that would look through the code, spotting private functions and checking if they have any references, if not, inform the user of the situation.
It wouldn't be too tricky to create one myself, but I was wondering if there were any accessible apps that could do this with the files containing the code?
My code is in c#, but I can imagine that this question covers a variety of coding languages.
ReSharper does the job.
If your code has Unit Tests (it does, right? ;-) then running NCover will allow you to identify methods that aren't being called from anywhere. If you haven't got any unit tests then it's a good excuse to use for starting to build them.
In the general case, I'd suspect that code coverage tools are a good fit in most languages.
Eclipse does it automatically for Java, not sure if you can have same thing for C#.
Another question might even be "Does the c# compiler remove private methods that aren't actually used?".
My guess would be no, but you never know!
EDIT:
Actually, I think it might be hard to tell where a method is used. It might be private, but it can still be used as Event Handlers. Not impossible to check, but I'm sure that aspect would make it a little more difficult.
Is there a quick way to detect classes in my application that are never used? I have just taken over a project and I am trying to do some cleanup.
I do have ReSharper if that helps.
I don't recommend deleting old code on a new-to-you project. That's really asking for trouble. In the best case, it might tidy things up for you, but isn't likely to help the compiler or your customer much. In all but the best case, something will break.
That said, I realize it doesn't really answer your question. For that, I point you to this related question:
Is there a custom FxCop rule that will detect unused PUBLIC methods?
NDepend
Resharper 4.5 (4.0 merely detects unused private members)
Build your own code quality unit-tests with Mono.Cecil (some samples could be found in the Lokad.Quality the this open source project)
Review the code carefully before you do this. Check for any uses of reflection, as classes can be loaded and methods can be dynamically invoked at runtime without knowing at compile time which ones they are.
It seems that this is one of the features proposed features for the next version of Resharper. That doesn't help yet, but hopefully the EAP is just around the corner.
Be careful with this - it is possible that you may remove things that are not needed in the immediate vicinity of the code you are working on but you run the risk of deleting interface members that other applications may rely on without your knowledge.