We Keep Coding

Is there something better than preprocessor directives (#if, etc) in C#?

Most questions of this type are seeking to alter the program behavior (things that could be decided at run time) or want to deal directly with debug printing. This is a bit different.
I have code that depends on a peripheral (like a card reader). Sometimes I don't use it, which means the library isn't present. (And I'm being nice, because "library" turns out to mean installing a 2GB software suite). When I remove the library, I can't open the device. If I can't open the device, I can't create the class member that uses it. With the class inoperative, I can't call its methods from within the code. Therefore, I can't just choose not to execute it; I need it to go away since it will not compile without the library.
Preprocessor directives like #if and all that are ok, maybe; but these things appear in more than one file, which means independently maintaining a #define at the top of each. I come from a simpler place (meaning, C) where one header file can be used to control this. I note that C# is rather hostile about #define (either the label exists, or not; no constants or calculations allowed), and that makes me think there's another way.
How do you handle this?
---Follow-up(s)---
I did read the "duplicate" Q/A's, and have a fairly good picture of what I'm dealing with. I didn't find those questions in my original search, but sometimes that's just how it is.
#Amy suggests that #define at the top is "not how it's done" but rather "put it on the command line". So, (if I realize we are sticking with this mechanism) the discussion might go to examining ways to have that happen . One does not simply drop to a terminal and do that. It happens as "IDE features" or "IDE hacks".
#Alexei Levenkov asks what I really want. I really want to (a) not get compile errors, and (b) do it by selectively leaving out the code. And, find the C# equivalent to the way I proposed.
Some more constraints are addressed by the fact that I haven't been using VS or C# for all that long. So I know a lot less than you all do. Considering I got the code from the last person and have to deal with what I see, I don't want to set up the person after me to have to figure out what "interesting" thing I might have done to make it work. Thus, things like hand-editing a project file may work but will also cause consternation down the line.
# Eric Lippert suggests "hostile" is really "sensible". I may have had my tongue too far into my cheek on that one. VS seems to be telling me I'm doing it wrong, so I sensed there's a "right way" I simply don't know about. As for the 2GB supporting application, I will go to various computers and pull down the repository and try out something, and so this "overhead" wants to propagate with it. It's worse if I'm linked through my phone to do the download. And if I build the application with everything included, the end user is then required to install that software suite before the program will run. In theory, they could be required to buy the software. If I sent you a tic-tac-toe game, and told you it wouldn't run until you installed Oracle, you'd probably pass on the whole thing.
I considered the "stub out the interface" idea, but there seemed to be more hooks into the class than I wanted to deal with. Plus, I don't know what these things do, so I have to know something about them in order to "fake" them.
In the end I decided that we're still largely using the #if scheme to get this done, and the replacement feature I imagined might exist, doesn't. And I'm using the provision in the project file(s) as cited by #Jim G. as it gets the job done and is only a little imperfect. It's good enough.

As #BJ Safdie said here:
Set them in your Compilation Properties or Build options.
You get to the build options by right-clicking the project and selecting
properties from the menu.

Tracking how resources are used at runtime to find missing translations

We maintain an ASP web app, which has a publicly visible interface that has to be localised into a large number of languages, and a private interface that still needs localisation, but only into a subset of the languages.
As much as possible, when we localise we put them into different resource files according to whether the string could appear on the public interface, or only the private one. However, inevitably mistakes are made, and I'd like to find ways to find resources that have been classified incorrectly. There's a lot of code shared between them, so the assembly that some code is in is not sufficient to determine this.
One way of doing this would be to record the resource name & location of every resource that gets accessed via the public interface, which allows us to (a) detect any that have been misclassified as private, and (b) investigate any that have been categorised as public but don't appear in this list. It looks like this might be possible by providing custom resource providers that wrap the default ones but record resource keys.
An alternative, but potentially more useful, option would be to record when a resource couldn't be found in a specific culture, and the system has had to fall back to the invariant culture resource. This will help us track down any untranslated messages. However, I'm struggling to find a way to do this.
Are there any good solutions here to avoid me writing my own? How do others manage similar scenarios? We'd rather avoid the cost of unnecessarily translating strings that can only be seen in the private interface into languages that it's not supported for.

In the interest of full disclosure, I'm the (sole) author of a commercial localization program for Visual Studio. I therefore stand to profit if you decide to research and purchase it. I'm not here to sell you a copy of it though (I don't work that way). I'm trying to legitimately help you and my program may be able to (though it's still unclear to me at this stage). You'ld also have to be open to a paid solution of course, assuming you can't find a better way. If I knew of a way for free I'd post it here. In fact, if my app didn't take so long to originally develop I would have given it away for free. I suggest you download the evaluation copy at http://hexadigm.com/FreeDownLoads.aspx (developer's version) to get an idea of what it can do (and ideally read about it on the site first). The evaluation version can only translate 10% of your strings however so it may be unwieldy to properly test what you're after. The program may have potential ways to deal with your situation though, if I understand it correctly, but it remains to be seen (for instance, you could bundle your public and private strings into separate ".trn" files, which you'll learn about if you research the app, but you obviously need to identify these strings first of course - how my app can help in that regard is still unclear). The upshot is you'll need to get a basic understanding of the program first though. It may be better to contact me offline at support#hexadigm.com. I don't believe any further discussion here will benefit other users but if the moderators feel otherwise then they can weigh in (I'd be happy to discuss it here if they wish, since the app does address various localization deficiencies in Visual Studio, but I don't want to violate the site's rules - I'm not here to promote the app so I won't discuss any specifics without their approval).

Isn't accessing private fields and properties due to reflection a security issue?

I just recently found out here that it is possible (at least in c#) to look up private fields and properties due to reflection.
I was surprised, although I knew that somehow constructs like the DataContractSerializer class need the possibility to access them.
The question now is, if anyone can access every field in my classes, this is kind of insecure, isn't it? I mean what if someone has a private bool _isLicensed field. It could be changed easily!
Later I found out here that the field accessors are not meant as a security mechanism.
So how do I make my Application safe, meaning how do I prevent anyone other than me from changing essential status values inside my classes?

The question now is, if anyone can access every field in my classes, this is kind of insecure, isn't it?
Not everyone can. Only code with sufficient permissions - trusted code. Untrusted code is restricted quite a bit. On the other hand, if the person who wants to use reflection has your assembly, they can run trusted code on their own machine. That's not a new attack vector though, as if they've got your code they could also modify it to make the field public in the first place.
Basically, if code is running on their machine, you should expect them to be able to do pretty much anything with it. Don't rely on access modifiers to keep anything secret.
So how do I make my Application safe, meaning how do I prevent anyone other than me from changing essential status values inside my classes?
If the hostile user is running your code themselves, you pretty much can't. You can make it harder for them, but that's an arms race which is no fun.
So one option in some cases is not to let anyone else run your code - host it on the web in an environment you've locked down. That's not appropriate in all cases, of course.
If you have to let users run the code themselves, you need to weigh up the downsides of them tampering with the costs of making that tampering difficult. We can't really help you with that balancing act - we don't have any idea what your application is, or what the costs involved are (reputational, financial etc).

private public and so on are a part of http://en.wikipedia.org/wiki/Encapsulation. the use is to make your API clear and to avoid mistakes.
there is no solid way to avoid people messing with your program.
you may have noticed that all programs are cracked in a few days usually.
in .net it is VERY easy because of IL code been very readable http://ilspy.net/ and such allow you to take any DLL and just read it like C# code.
you can make it more annoying to read your code using obfuscator
http://en.wikipedia.org/wiki/List_of_obfuscators_for_.NET
but applications like http://de4dot.com/
break this VERY easily.
SecureString is a nice trick: https://msdn.microsoft.com/en-us/library/system.security.securestring%28v=vs.110%29.aspx
writing your code in low level language like c++ might make cracking your code really annoying. but soon a skilled hacker will do whatever he wants with your program.
the only option that might be safe is providing your application as a cloud service where the user only sees the screen output and sends keyboard/mouse input.

This was meant to be a comment for John Skeets answer but ran out of room..
Great answer by the way, but I also must add that code is not meant to be secure its meant to clearly defined.
Most developers know how to change classes and inject into classes. There are many utilities to not only decompile your code but to also allow injection into it.
I wouldn't spend to much effort trying to your make code more secure, I would try and expect the code to be changed. Many programming languages do not have such modifiers as private, public, internal, protected etc. They rely on the developers to understand the consequences of using this code on their own. These programming languages have been quite successful as the developers understand that modifying, calling or injecting into code the API does not specify has results that the developing company cant and will not support.
Therefore, expect your code to be modified and ensure your applications responds to invalid changes appropriately.
Sorry if this seems like a comment...

To add to all the other answers, a simple way of looking at it is this: If the user really wants to break your code, let them. You don't have to support that usage.
Just don't use access modifiers for security. Everything else is user experience.

C# proper way for file associations

I've been looking for a proper way to get file associations working on WinXP and above. The association should be replaced if it already exists. The application I've developed always run in admin mode, so rights shouldn't be a problem.'
I've come across some old posts that had some sample code, but some of them didn't work well enough and some not at all. I'm using this post to make a final desicion on the method I will attempt to use and am looking for as much feedback as possible.

I think you need to make changes to the registry as shown here
http://msdn.microsoft.com/en-us/library/cc144154%28v=vs.85%29.aspx#registration

Verifying license information without a boolean check? [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 7 years ago.
Improve this question
I'm currently using a simple XML file that contains license information along with the data's signature and public key. So far, this method is working great. However, I'm seeing one rather large security flaw...
When my ASP.NET MVC application starts, it verifies the license and sets the "ValidLicense" bool property accordingly. During each request, this property is checked and an error message is displayed if the license is invalid.
As you can guess, there's absolutely nothing to stop a competent user from simply modifying my assembly to set "ValidLicense" to true regardless of the license's validity. I know this can be done to pretty much any application, but it seems incredibly easy to do with .NET assemblies.
What are some ways that I can stop this from happening, or at least make it a little more difficult to crack the license verification procedure?
I'd rather stay away from assembly encryption and obfuscation systems, if possible. Go ahead and suggest them if you feel that they are good enough to warrant the cost and extra headache, however.

The only way to win is not to play.
The people who are going to steal your stuff (regardless of what protections you put in place), are not the people who are going to pay for it if it's too hard for them to break.

Instead of a simple boolean variable, you could perform a complex calculation every time you need to verify the license and base your logic on the result from that calculation. You do get a perf hit, though. And cracking your assembly wouldn't be that much harder anyway.
You could also employ some more advanced techniques, like dynamic mutation of the code and using the a corresponding mutable function to control the flow of your logic.
However, you should ask yourself does your assembly really contain such precious intelectual property, as to warrant the time and efforts to implement anything like this? It might be more viable and cheaper to go the legal route and battle the potential piracy if and when it occurs.

You can make it a bit more complicated but in the end it will come down to one (or several) booleans: Either you run the code or you don't. Non-obfuscated.NET code is pretty much the same as open source and it is ridiculously easy to crack open.
Even if obfuscation is not a full solution, I think it would make sense to obfuscate, just to prevent fringe amateurs from producing cracked versions.
Of course it won't stop a real cracker who is willing to spend the time, but just by putting the bar a little higher, you can weed out a lot of crackers wannabes.
Obfuscation can be pretty simple to implement for free. If you have a commercial version of Visual Studio, you can use DotFuscator (not with the "Express" editions). I never tried, but I guess it should be simple enough.
Otherwise, you can use Assemblur. (http://www.metapropeller.com/). The free version is a command line application (there is a GUI to create the setting file, but you need to run the settings from the command line).
All in all, it barely takes a couple minutes to obfuscate a simple exe file and it's free
If you want to make your license check a little more challenging, you can make different checks inside various methods, and you can also make sure that the license checking code does not actually output any string directly. (for instance, you do a license check in method A, but you output the error warning from method B, so that when a cracker looks for the license error message, he doesn't land right on the bit of code to be changed).
All it does is raise the bar for wannabe crackers and make things more complex for a real cracker.
Case 1: Non obfuscated .NET application with 1 license check method which output a "not licensed" error message.
Can be cracked in about 5 minutes by anyone who can run reflector.
Case 2: Obfuscated .NET application with a couple different license checks and no obvious string output.
Could take hours for a cracker and prove too hard for a wannabe.
You can get from case 1 to case 2 with about 1 hour of work, without spending a dime. Going beyond that is probably a waste of time (everything can be cracked) but at least, you can weed out the folks who open your application in Reflector just to see if it's going to be easy. If the guy opens the application in reflector and sees something like:
public bool ValidateLicense(string sLicense)
{
string sInvalidLicense = "Your license is not valid";
...
}
Guess what happens next?
//EDIT: In a comment, LC asked:
How do you not have it output any string message but still notify the user? Even if you do a license check and output in two different methods, you'll still have a the binary decision "if(!ValidateLicense(LicenseCode)) {NotifyUserOfInvalidLicense(); throw new LicenseException();}" or something, no?
Put yourself in the shoes of a cracker: You are looking for the License validation code. You are not going to study the whole code just to find it. Instead, you run the application unlicensed: The error message shows up.
You take that error message, you open the assembly in Refactor and you search for a part of that error message.
If that string is located inside "ValidateLicence()", you immediately find the ValidateLicence() function. From there, you only need to locate the return value and change that 1 byte. Done.
If the string is found instead inside "WhatEver()", you still needs to find what methods call "WhatEver()". It might not even be in the same assembly (in which case Refactor will not find it for you). This makes the job harder for your wannabe cracker. He will have to look at that method to see how it validates the code (which it doesn't). He might even be sloppy and change the return value of the wrong method, in which case he introduces a bug (if the method is obfuscated, figuring out what it does is not that simple).
Better yet, don't use a string at all: you can store the error message as a sequence of hex codes, and convert it to string dynamically when you need to display the message. No error string means that the cracker will have to rely on something else to locate your license validation code. And reading through obfuscated code is not fun.
You could also have a fake validation method containing the error message and suppress the warning to make it look like the crack worked.
So, a couple of simple, stupid tricks like these + simple obfuscation are very easy to implement and they can turn a 5 minutes "In and Out" cracking session into weeks of work for the cracker, because not only does he need to find and crack your validation code, but he also has to test to make sure that everything is working and that he didn't just fix a decoy or unwillingly created nasty bugs. Now, he just can't be sure without testing.
In the end, cracking an assembly is just a matter of changing a few bytes, and you can't prevent anyone from changing bytes in your assembly's files. Everything can be cracked.
However you can make it a hell of a lot harder to find which bytes have to be changed, and at the very least, you can avoid having a string that says "the byte you are looking for is right here".

An approach I met when trying to hack a little .NET product was to use an unmanaged .DLL for the licence checking. And not only that, the .DLL also contained a lot of code that was actually used in the software. So, to crack product I actually had to crack the unmanaged .DLL (or make a perfect wrapper). Needless to say, this stopped a wannabe cracker like me. :)