I have a fairly large code base sprinkled with a bunch of DateTime.UtcNow, many other calls and TimeSpans, etc.
Now we are introducing tasks with timers, etc and I need to run the system at a variable speed to debug, like a day is 5 minutes, etc.
Since there are a lot of things depending on time and I can't change the logic everywhere, I can do two things:
Create a fake assembly in Visual Studio so I replace DateTime; Or,
I can simply change all the DateTime calls to my own class which would normally just return results from DateTime.
But, ultimately, it boils down to writing a replacement of DateTime and since the code is using more than DateTime.UtcNow, I would like to find a existing solution if possible.
Does anyone know if such a thing exists? I haven't found anything so far
Have you tried mocking?
I would create an interface that returns the time a task must run. That would let you create two classes one for debug and one for release, that way when you are debugging you can return whatever value you need and you won't need to worry about how core classes work.
I hope it helps!
Related
The question is kinda hard to understand but what I'm trying to do is to launch a program and make that program think that the system clock is "some other date and time" and not actually change the system time. How can I do this programmatically using C#?
P.S: I can't alter the program I launch in any way.
EDIT: I just realised that the program checks the time only once after ~4-6 seconds of startup. So I will just change the system clock for 10 seconds and restore it back! Thanks for all the help!
You will have to intercept calls to winAPI like GetSystemTime. C# is not the best instrument for such thing, but nothing impossible. Use any detours library that supports C#. Think of a way to modify program address space (remote thread, WriteProcessMemory, filter DLL).
That is a very general idea of where you may find the solution.
Though if you will ask how to intercept program calls to OS, you will hardly get any answers here, at least if you show no own efforts.
If you know what date/time functions your application uses, you can investigate which system calls those CLR methods use. Once you know, you can test your software in an environment where those calls are intercepted, presumably giving "fake" responses to e.g. DateTime.Now in .NET.
There are utilities that do this for you, for example http://www.nirsoft.net/utils/run_as_date.html
I don't know if the specific system calls intercepted by that utility is the ones used by the framework to give for example DateTime.Now
This is the old question but my answer will probably help someone.
What we do in our project is to use interface like this:
interface IDateTime
{
DateTime Now();
....
}
Then you use IDateTime instead of regular DateTime just everywhere and IoC to get instance of IDateTime.
So, as result you can create any implementation of Now().
Really helpful when writing unit tests.
Is there some way to force DateTime.Now to always return DateTime.UtcNow for application?
--edit
My intention:
I have big datetime-very-sensitive application. I cant rewrite all places where it is (time consuming). Programmers sometimes in time pressure forgot to use utcnow.
I think the best option for you is to use a mock to return datetime in your application.
For unittesting or other function you can use a custom DateTime
Take a look to this:
http://blog.coreycoogan.com/2009/06/07/mocking-datetime-now/
I cant rewrite all places where it is (time consuming)
Yes, and that takes like one minute (replace file in files) plus your unit tests telling you what fails.
The alternative is to mess up the behavior for new parts of the program where the user MAY NEED the local time for whatever reason. Seriously, sit down and clean up the program.
DateTime.Now is static, so it has to be in this form, finding that is trivial. fixing those cases will be relatively, except you have to add stuff like conversion routines for input and output - and you have to do that in any case.
I have a lot of shared business logic code between C# projects and Script#.
Since the breaking change in script# core library (when DateTime class became Date) things gone south.
Has anyone come up with generic bulletproof solution how to handle it?
I read some people said they wrote a wrapper, but no one showed their sources.
There can be some pitfalls, like JS Date counting months from 0 and C# DateTime from 1
& so on, so it's not exactly trivial wrapper...
Forking the original script# and renaming Date back to DateTime is not really an option, since then you'll need to work on two project - yours and the fork.
References:
Issue 119 - DateTime class is missing in 0.7.4 Release
Issue 67 - Compile-time error with Nullable DateTime / user Enumeration.
Script# - Release History: projects.nikhilk.net/ScriptSharp/ReleaseHistory
P.S.
I'm aware of #ifdef solution, please don't suggest it ;)
One potential approach is to store just the tick count as a long within your data model. Then use a set of helpers that interpret the ticks as a date/datetime and provide the APIs you're looking for. Just a thought... given the semantic differences, some wrapper/abstraction is anyway required for those who want to share code, and this is one approach for building that.
One side-benefit to this approach is serialization to/from json is simplified ... a) since there is no date literal syntax in JSON, and b) because the precision of ticks is different across script and .net ... so at the least if you use the .net tick count and it is not updated on the client, it just roundtrips without loosing precision.
If you do build this, this would be interesting to share back to the community.
I have the situation that the same repeating refactoring tasks have to be done for a huge number of methods in my code.
For example imagine a interface with 100 methods, each of them has one or more parameters as well as a return value. For each of these methods I need to jump to the implementation change the return type and add a line of code which converts the old return value to its new type for callers of the interface method.
Is there any way to quickly automate such refactorings?
I even thought to write a custom script to do it, but writing a intelligent script would approximately take longer than doing it maually.
A tool supporting such task can save a lot of time.
It's a good question, but in the time it took since you posted it (not to mention the time you spent searching for an answer before posting), you could have completed the changes manually.
I know, I know, it's utterly unsatisfying, but if you think of it as a form of mediation, and only do this once a year, it's not that bad.
If your problem is one interface with 100 methods, then I agree with another poster: just doing it may seem painful but it is limited in effort and you can be done really soon.
If you have this problem repeatedly, or you have very large code base (many, many interfaces for which you want to perform this task), then what you need is a tool for implementing automated change: a program transformation engine. Such a tool provides the ability to parse source code, build a program representation (an abstract syntax tree), and enables one to apply "scripted" operations on the tree either through procedural interfaces and/or through source-to-source transformation patterns.
OUr DMS Software Reengineering Toolkit is such a program transformation system. It has a C# Front End to enable its application to C# code. Configuring such a tool for a complex task is not a matter of hours, so it is not useful for "small scale" changes. For large scale changes, such tools can make it possible to do things simply not practical by hand.
Resharper and CodeRush both have features which can help with this kind of task.
Resharper's change signature functionality is probably the closest match.
Can't you generate a new interface from the class you have and then remove the ones you don't need! if it's that simple!!
change the return type : by changing... the return type, provided it is not a standard type (...), and the converter can be implemented by a TypeConverter.
When i have such boring task to do, i often switch VS2010 and use a tool that allow regex search and replace. In your example, maybe change 'return xxx;' by 'var yyy=convert(xxx); return yyy;'
(for example editor Notepad++ (free) allready offers quite some possiblities to change everything in a project (use with caution))
We have a large (about 580,000 loc) application which in Delphi 2006 builds (on my machine) in around 20 seconds. When you have build times in seconds, you tend to use the compiler as a tool. i.e. write a little code, build, write some more code and build some more etc etc As we move some of our stuff over to C#, does anyone have a comparison of how long something that size would take to build? I only have small apps and components at the moment, so can't really compare. If things are going to take a lot longer to build, then I may need to change my style! Or is my style just lazy?
For example, if I'm changing the interface of a method call, rather than do a full search on all the app to find out where I need to make changes to calls, I'll use the compiler to find them for me.
Visual Studio 2008 SP1 now has background compilation for C# (it's always had it for VB.NET). Back in my VB days, I often used this to find where something was referenced by changing the name and then seeing where the background compiler said there was an error.
I never worked on anything quite this large. At my last job we had about 60,000 loc spread over about 15 projects and it took about 10 seconds to compile. Maybe someone else can post a slightly larger case study
I used to use the compiler as you describe, but since I've been using ReSharper I do this a lot less.
Also, for things like rename, the refactoring support (both in Visual Studio 2005 upwards and, even better, from ReSharper) mean I don't have to do search + replace to rename things.
One thing you can take advantage of, especially in desktop apps, as I imagine you are dealing with coming from Delphi, is Edit and Continue. This lets you change actual code while you are running in debug mode. You can change just about anything, except for adding class level variables, methods, or new classes, and still continue running without having to recompile your project.
I use only the "Syntax Check" to see if I forgot some typo on the code... And these are much reduced, since I the "Code Proofreader" of GExperts plugin.
Well, compiler doesn't have to be that fast to take advantage of it. Some IDEs support incremental compilation on every file save, or either on-the-fly. This works great.
You can split application in several projects ( by layer and/or module and/or etc... ) and you will compile only project, where do you actualy work.
The last part of your post scares me. I am not familiar with other IDEs but MSDev allows you to find all references to a method - so you don't have to compile just to find all the method calls you broke.
Use whatever works, but it is good you are open to new ways of doing things.