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.
Related
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!
I'm trying to write a log to monitor the execution time of a method for our application. Is it possible to know when a method in a class is being executed without using Aspect-oriented programming.
I don't want to go into every method to write a log there so I hope someone faced this issue and can give me some suggestion.
Updated: I'm writing a SharePoint application using .Net 3.5
AFAIK, without AOP or directly logging code injections the only way is a profiling API.
I wouldn't choose that way for one-time task, it isn't easy.
Try using breakpoints. Press F10 on the space at the left side of the method, and from there, the debugging starts, where you'd be able to see value and property change after its execution.
Addtional to #Dennis answer, I think System.Diagnostic.Debug is a choice to know when your method is executed beside Aspect-oriented programing. However, you need to turn on Debug build flag, or supplying argument in csc.exe
/define:DEBUG
in sp 2010 you can turn on developer dashboard (on dev stage only for safety)
this will give you abreakdown of calls and times
http://msdn.microsoft.com/en-us/library/gg512103(v=office.14).aspx
I want to test my trading system by playing execution reports back into my application. Then I could verify that my order/position state is correct.
I found this somewhat related question: how to replay a quickfix log
The difference is that in the article the person was looking for a whole testing tool that would play back a log file. What I was wondering is whether there exists a utility that will take a string representing a FIX message and then just generate a FIX object (ex: ExecutionReport).
Does anything like this exist out there? Has everyone just been writing their own?
It sounds like you simply want a different kind of test tool.
If you've written your app in unit-test-friendly fashion, then you could simply write unit tests to create ExecReport objects and pass them as parameters into some ExecReport-processor component. (I'm guessing you're not designing for UTs, else you probably wouldn't need this suggestion.)
If not, then I think the best thing to do is write another app that your first app can connect to. You could create a simple Acceptor app that can use command-line commands to trigger ExecReports to be sent. If you're using QuickFIX/n (the C# port), you could steal code from QuickFIX/n's example apps "TradeClient" and "Executor".
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))
I want to set expire date for my C# Windows application.
It means that i.e after 30 days my app won't work. It is easy to do when we use system time, it means whenever my program starts i check today date and expire date.
The problem is if the user changes system time, my comparison won't be correct.
What other ways can this be done?
I would figure out a better way to get people to want to pay for the application, because fighting it can be a very futile effort, although you can make it more difficult with things like hardware dongles, phone home services, etc. If your price point is not high, customers won't want to put up with this.
May be keep a dummy .dll file in your app install folder, open it and keep the number of days and install date time. Every time application loads up, check it. .Dll files folks wont try to open and read. May be you can encrypt and store in it too. This could be very simple.
The first line of defense is to check with a server, checking out their system time so that the user cannot change his own. Also try to hide the start date (under some dummy name in the registry perhaps). These are pretty futile things though, smart users will be able to 'crack' this with minimal effort.
It's trivial to disassemble a C# application, so whatever you implement will be liable to easy circumvention. The best choice, in my opinion is to use third-party Licensing tools but do bear in mind that all can be circumvented, although they will be more robust.
How likely is your app to be pirated and is it worth the time/expense to do anything more than cursory checks?
It might be easier to simply have two versions of a DLL - one that must communicate with a server every X days to make sure it's still active and the "unlocked" (purchased) version.
As has been noted, determined users will find a way around whatever you do so you have to evaluate effort/return to determine how much attempting to secure your app is worth.
You could use a website that keeps the time to determine how long the program was installed.
You are probably going to get advice saying that it is not woth your effort.