I know that there are a number of tools for analysing .NET code and calculating the coverage, plus identifying classes/methods/properties etc that are never going to be hit.
However, I am trying to clean-up a legacy application that I am certain contains an amount of unused code - however a lot of code is accessed via some arbitrary and complex reflection tecniques that will disguise the intent to the compiler - thererfore any coverage tool that only analyses the compiled code is unlikely to generate any reliable reports on code useage within this application.
Are there any tools that work rather like profilers, whereby they listen to a running application and log what classes/methods/properties are actually hit and generate the coverage based on this data.
I hope Ive made everything clear - thanks in anticipation
we are using ncover, and it works really nicely: http://www.ncover.com/.
But it's commerical, or you use the trial version, if you just need it once.
You can use the VS2010 Code Coverage tools - they do use Instrumentation (which means reflection won't trick it). Syed Aslam Basha has a post on it in his MSDN blog on how to enable it for manual testing (which it sounds like you will need to do).
Just remember you will need to click every feature etc. while its running; or just think twice before deleting code - but it should give you a good starting point.
Two open source versions currently exist that support .NET2 and .NET4 runtimes
PartCover - is the oldest but only supports 32 bit (supported by teamcity)
and
OpenCover - is the latest, it again supports .NET2 and .NET4 but also supports 64 bit, it also has recently added branch coverage (though reporting is up to the user)
Both OpenCover and PartCover can be used with TypeMock and Moles should you need to.
Commercial versions include (but no limited to)
NCover - the most well known
dotcover - integrates well with team city when unit testing
Clover.NET can do this. But it is commercial and I didn't manage to find a link to the .NET version (I've used it several year ago).
Can't think of a tool other than a profiler, but how about using logging?
Use static analysis to discover static calls, and put logging into the reflective invocations to show what is being called. After a few runs you'll know what is being run.
After all the reflective invocation will know what's doing.
Related
I need to debug the performance of a slow application that sometimes gets slow and sometimes works just fine.
It's really hard and I can't find what's the problem.
I thought about IL weaving and tools like PostSharp. But since I only want a very specific requirement, I thought maybe there are other ways/techniques that I'm not familiar with.
My need is to log the overall execution time of each and every method. How can I get that? Is IL weaving the only option?
You do that with a profiler, e.g. dotTrace for C#. If you have Resharper Ultimate, dotTrace is included.
.NET profilers do not only measure the time of all your methods, but also the time in .NET garbage collection.
There's also a profiler available in newer versions of Visual Studio.
Although it could be done with IL weaving as well, you would not compile an extra version just for this purpose. With a profiler, you can change the settings without recompiling your code every time.
The profiling tools mentioned in other answers allow you to analyze the application performance in a controlled environment on your development machine. This can help you to find which sections of code need optimization.
However, you may also want to monitor the application performance in the production environment. This can help you to find out which other factors external to your code and specific to the environment are affecting the performance.
For the second use case you can check out PostSharp Diagnostics Framework (http://doc.postsharp.net/logging). It allows you to include detailed logging into your application including method execution time and is highly configurable. The logging can be turned on and off in the configuration, so there's no need to create two separate application builds.
Another option to look into is an Application Performance Monitoring tool installed in the production environment. A quick search will give you examples such New Relic APM, DynaTrace, AppDynamics and others.
In the end, it's up to you to make a choice of specific tool based on your use case and budget.
Speaking about compiled languages (c# in my case) I think that problem would always remain, no matter how performant your develop machine is. Build time could be more or less depending on concrete environment, but often it's enough to make your attention wanna move from your task to something else like stackoverflow, youtube, twitter etc. and it's just very annoying.
I'm happy for java developers because of Java's dynamic class loading, but what can .net (and others) developers do to make build process less painful and obtrusive?
We use multiple build configurations to trade-off between speed and a comprehensive build.
A full build does time-consuming things like FX cop analysis, ASP.NET compilation, all unit test projects, Entity Framework view pre-generation, etc.
A "fast build" typically takes just a few seconds and those the bare minimum needed to get the project running.
Developers switch between the full build and the fast build throughout their workflow, as needed.
Don't the class files have to be build as well? Wouldn't that just put the workload to runtime in contrast to compile time? That's not really a difference isn't it? The bigger software grows, naturally, the longer it takes to build it, depending on the machine and not on the language or framework - this is the tradeoff for things like strong typing, interpreted byte code (or binary code depending on the language/compiler) instead of interpreted source code at each run (as you have with php and python etc). I don't think java improves things much, there will a timeframe you have to build your application in.
I think in comparision to C and C++ both C# and java have improved immensely on the account of compile time.
Just use the time for slacking off:
source
Some things to try:
Defragment the drive containing your source code
Exclude your source code folders from the virus scanner
Exclude your source code folders from the Windows Search indexer
Disable any Visual Studio extensions that you are not using
The remark in your question about one's attention wandering off-task reminded me of this Joel on Software post.
So investing in solid-state disks (since I'm assuming you're talking about the build process on a dev box while you're developing and debugging) could help.
Besides, making your computer faster in general can't hurt, right? :)
In addition to many of the other suggestions to get a faster machine, remove unnecessary projects from your solution, etc, consider Visual Studio 2010 + a multicore machine. VS2010 can take advantage of all of your cores when doing a build. Check out this thread for more on how to set that up.
Are you doing a rebuild all every time or do you have everything in the same assembly? I'm working with quite large projects and my build time isn't that high. I got several assemblies and I only modify a few each time I do changes to the project.
If you find yourself modifying assemblies all over the place, you might try to refactor your code structure. Or maybe you haven't taken yourself time to do unit tests? They do not only help you with the testing, but to get better code structure (hard to test apps with lousy design).
Another alternative is to use tools that speed up builds, for instance: http://www.xoreax.com/
I've worked on some very large C# projects and have rarely seen Debug build times exceed 2 minutes.
What generally sucks time are things like static analysis (e.g. fxcop), unit tests, code signing (if using a code sign service), etc. The easiest way to keep these under control is to either limit them to Release builds or to have a separate build definition for 'Full Build' and exclude these steps from your Debug and Release builds.
If these aren't your problems, look to your computer performance as others have said. Fragmentation, slow build disks, anti-virus, etc.
I'm planning to setup my own build server. I'm primary building C#, C/C++ and Java projects. I would also like my build server to run some external programs/scripts such as my unit tests, code static analysis and doxygen.
Suggestions?
Use Hudson Continuous-Integration software.
We're using JetBrains TeamCity. It's easy to configure, user friendly, has convenient plug-ins for notifications on build events, you can install multiple build workers, define any build engine (.net, java...), it can output artifacts, it can trigger automatically on check-in, it can execute any custom build script etc, etc... and most of all - it's free (for up to 20 configurations).
We've looked far and wide, and we found this to be the best...
Hardware: Discs. Quite some, or a decent SSD. A lot of the stuff you do will be disc based from the compiler side. Not talking about the get latest version (alone), but for example a c++ compiler generates QUITE a number of interim files in the build process. A decent fast subsystem can make a recognizable difference. Especially fi this is not for you but for some colleagues as well, sotit may run a lot concurrently.
Well, enough RAM and a modern multi core CPU go without saying.
I've used Trac and Bitten, which worked quite well. I used it for C# and Python projects.
I have it building, creating docs and running unit tests. Currently I'm investigating running dotCover for test coverage, which shouldn't be too difficult, because bitten basically allows you to call any shell command you need.
Actually, I usually run the build system on an old (not-so-fast) system - it doesn't need to be very quick for me. I like to have developers behind the fast machines ;-)
target state: Porting VB6 Code into C#, undertake the whole project with all conceivable processes that are involved.
What would be your approach if you do not have knowledge about the domain?
There is nearly any documentation, just legacy code (up to 100.000 - 300.000 lines of code and comments vb6 files that contain up to 14.000 lines of code) written in VB6.
Disclaimer: I work for Great Migrations
We rewrite large VB6/ASP/COM applications to .NET (primarily C#) for a living and we have developed a software analysis and reengineering tool to help us do it. This tool is essentially like a VB6/ASP/COM compiler and a decompiler that authors .NET codes. Of course since the VB6 platform is very different from .NET, a direct compile/decompile is not desirable or viable, so our tool has an "analyzer" that implements various code reengineering algorithms to deal with VB6-C# incompatibilities. There is also a programmable "author" that allows the migration team to prescribe rules for setting up .NET code files, restructuring the code, and doing things like replacing COM APIs and ActiveX controls with .NET classes -- depending on what the team needs or wants.
As a by product of compiling and analyzing the code our tool produces a model of the entire VB6/ASP/COM system being upgraded. This model can be used to produce extremely detailed reports about the internal structure of the system. These models can be used to help reverse-engineer the code -- if you know the right questions to ask and you would need to understand the problem domain to do a good job.
Of course once you have build-complete .NET, you can use the various analytics and code review tools that work off assemblies. Some versions of Visual Studio have these tools and there are open source tools such as FxCop, NDepends). There are also some fantastic dynamic analysis tools (EQUATEC Tracer) that I have used.
In the end though migration teams are going to very hard pressed to verify any unknown system. Even if you are staying on the same platform, you would unable to prove an application it is "correct" if you do not know how to run it and how to setup/enter expected inputs and find/verify expected outputs. We normally leave this to the customer!
If we are doing verification for the customer, we rely heavily on side-by-side testing to validate the new version of your system -- assuming we know how to run the legacy application we assume that given the same sets of inputs and usecases it should exhibit the same behaviors and produce the same results. I have heard this Approval Tests in unit testing circles.
I admit we also rely heavily on the knowledge that the VB6/COM code is a complete, detailed, formal and production tested description of the data structures and logic of the system and that we are putting this information through a tested and retested systematic transformation. We have been developing compilers since 1977 and we have worked very hard on this VB6/ASP compiler to make sure the .NET codes that we generate preserves the semantics of the original VB6. It is not 100% every time - but it is getting closer all the time. Then again doing things by hand does not guarantee 100% correct code on the first try either...
mark's answer about Great Migrations is excellent. Do be aware there are competitor automatic tools, which also have a very good reputation.
Artinsoft's VB Upgrade Companion
Francesco Balena's VB Migration Partner
Has anyone used Mono, the open source .NET implementation on a large or medium sized project? I'm wondering if it's ready for real world, production environments. Is it stable, fast, compatible, ... enough to use? Does it take a lot of effort to port projects to the Mono runtime, or is it really, really compatible enough to just take of and run already written code for Microsoft's runtime?
I've used it for a number of internal and commercial projects with great success. My warnings:
Write lots of unit tests and make sure they ALL pass under Mono -- this will save you a lot of trouble.
Unless you absolutely have to, do NOT use their embedding API. It's damn easy to use, but it's ungodly easy to garbage collect valid memory or leak all of your memory.
Don't ever, ever, ever even come close to SVN and unless there's no choice, do not compile your own. Things change so often in SVN that it's highly likely you'll end up implementing something that doesn't work on a release version if your project is significantly large.
Don't try and figure out problems on your own for long, use the IRC channel. The people there are helpful and you'll save yourself days upon days -- don't make the same mistake I did.
Good luck!
Edit: The reason I say not to compile your own from source (release or SVN) is that it's easy to configure it differently than release binaries and hide bugs, for instance in the garbage collection.
Edit 2: Forgot to answer the second part to your question. In my case, I had no issues with porting code, but I wasn't using any MS-specific libraries (WinForms, ASP.NET, etc). If you're only using System.* stuff, you'll be fine; beyond that, you may run into issues. Mono 2.0 is quite solid, though.
I find Mono to be mostly binary compatible with MS. Hence I simply compile with MS, and run anywhere, like Java is meant to be!
The performance of Mono on Linux is getting very close to MS, as little as 2 times slower in some cases, vs 5-10 times slower when running Mono on Windows (but you should really stick to MS then).
I had some experience with Mono.
Pure .NET stuff (like business logic, controllers or algorithms) can be ported without any problems. Yet, weird things start showing up in the components that interact with operating system, UI, services or persistence. So be prepared for some debugging and hacking.
Things that might help:
Component-Driven Development - so that code is reused by Windows .NET and Mono, while differences are isolated and tested)
Continuous Integration running and checking everything against Mono and MS.NET, so that possible issues could be discovered as fast as possible (automated deployment and sanity checks are also recommended)
There are not a lot of UI component suites for shell development in Mono.
When a component vendor says that his code is "compatible with Mono", it is not same as "runs on Mono and is supported".
Although in the present, there are some companies going into production with Mono, I'd still wait before rushing in there due to:
Lack of decent and commercially supported UI component suites
Issues with efficient garbage collection
Not the best debugging experience (compare with the historical debugger in VS 2010)
PS: if there is a company offering fully managed cloud computing solution (not just a VM, but more like Hadoop equivalent for .NET), then I'll be forced to jump in despite these issues.
If you are doing ASP.NET 2.0 work, it works very well. Winforms may work, but it can cause display issues. If you want compatibility in a forms app, I would suggest GTK#, as it is crossplatform.
Like suggested, as long as you thouroughly test, I would agree to using it commercially if that is a viable option for you, unless it is winforms you need. In my opinion, i would stay away from it for now. And forget WPF as there is no support at this time, and there may never be (although they are working on moonlight, aka silverlight for linux)
I haven't used Mono myself but you may be interested to know that FogBugz uses Mono to provide Lucene.NET on Linux platforms. (I only know this because Joel mentioned it in passing in Stack Overflow Podcast #24.)
I've got a bunch of shell apps in production.
I agree with #cody-brocious, write a lot of unit tests. I found in the past that Regular Expressions didn't work exactly the same way as the windows CLR.
It's actually simplier than you think to get into, just compile and run. If you use NAnt on your projects its even easier to transition.
I typically install mono from the source releases and I haven't had any problems.
I've used it for encryption/decryption tools and it worked fine.
In the future, I would consider using Mono/C#, but I would not expect it to be 100% exactly like .Net on Windows.
Of course, you can, especially after Mono 2.0 has been released.
Mono 2.0, is ready for real projects.
You can check this