We Keep Coding

Throw an error at compile time if a particular external function is used anywhere in the code?

I'm using an external library and I want to make sure I never call some particular functions in the library. I don't have the source code for that library so I'd like to make sure that at compile time it throws an error if I ever accidentally (or one of my developers) ever use that function. Is there a way to do this?

You can't do this easily. You could mark the method as obsolete, but of course that requires access to the external library source code, at which point you could also just remove the methods.
The next best thing I can come up with is to build a facade around the library object:
public class LibraryFacade
{
//All the library methods as pass-through methods
//Except the bad ones!
}
Of course, your developers have to actually use the facade for this to help. If you don't trust them at all, you could get new developers, or put the facade in a separate assembly so the client code doesn't have direct access to the external library.
Obviously thats a lot of work for this kind of feature, but it will get you where you are trying to go.

If you have plenty of extra time you can make a clone of the external assembly and link against your slimmed down version with identical method signatures instead of real one and replace with real assembly at run-time/post compile. Easy for non-signed assemblies, I think you can even do that if other assembly is signed by using delay-sign feature.
Benefits: complete intellisence/refactoring support, perfect build errors.
Drawbacks: picking right subset of methods may be major pain if library uses a lot of dependencies, getting 100% parity may be hard.

How does .NET's Primary Interop Assembly Embedding work?

I am researching the .NET Common Language Infrastructure, and before I get into the nitty-gritty of the compiler I'm going to write, I want to be sure that certain features are available. In order to do that, I must understand how they work.
One feature I'm unsure of is the .NET Primary Interop Assembly embedding. I'm not quite sure how .NET goes about embedding only the types you use versus the types that are exposed by the types you use. From the bit of research I've done into this, I've noticed that it emits a bare-bones interface that utilizes vtable gap methods, where the method name format is VtblGap{0}_{1} where {0} is the index of the gap and {1} is the member size of the gap. These methods are marked rtspecialname and specialname. Whether this is accurate or not, is the question.
Assuming the above is true, how would I go about obtaining the necessary information to embed similar metadata into the resulted application?
From what I can tell, you can order the MemberInfo objects obtained via their metadata tokens for the order, and the dispid information is obtained via the attributes from the interop assembly. The area I'm most confused on are the interfaces that are imported that seem to have no direct correlation with the other embedded types, sequentially indexed interfaces that seem to be there for versioning reasons. Is their inclusion based off of their indexing or is there some other logic used? An example is Microsoft.Office.Interop.Word, when you add a document to an Application and, in doing something with it, it imports the document, its events, and so on.
Here's hoping someone in-the-know can clue me in on what else might be involved in embedding these types.

Tool for 'Flattening' (simplifying) C# Source

I need to provide a copy of the source code to a third party, but given it's a nifty extensible framework that could be easily repurposed, I'd rather provide a less OO version (a 'procedural' version for want of a better term) that would allow minor tweaks to values etc but not reimplementation using the full flexibility of how it is currently structured.
The code makes use of the usual stuff: classes, constructors, etc. Is there a tool or method for 'simplifying' this into what is still the 'source' but using only plain variables etc.
For example, if I had a class instance 'myclass' which initialised this.blah in the constructor, the same could be done with a variable called myclass_blah which would then be manipulated in a more 'flat' way. I realise some things like polymorphism would probably not be possible in such a situation. Perhaps an obfuscator, set to a 'super mild' setting would achieve it?
Thanks

My experience with nifty extensible frameworks has been that most shops have their own nifty extensible frameworks (usually more than one) and are not likely to steal them from vendor-provided source code. If you are under obligation to provide source code (due to some business relationship), then, at least in my mind, there's an ethical obligation to provide the actual source code, in a maintainable form. How you protect the source code is a legal matter and I can't offer legal advice, but really you should be including some license with your release and dealing with clients who are not going to outright steal your IP (assuming it's actually yours under the terms you're developing it.)

As had already been said, if this is a requirement based on restrictions of contracts then don't do it. In short, providing a version of the source that differs from what they're actually running becomes a liability and I doubt that it is one that your company should be willing to take. Proving that the code provided matches the code they are running is simple. This is also true if you're trying to avoid license restrictions of libraries your application uses (e.g. GPL).
If that isn't the case then why not provide a limited version of your extensibility framework that only works with internal types and statically compile any required extensions in your application? This will allow the application to continue to function as what they currently run while remaining maintainable without giving up your sacred framework. I've never done it myself but this sounds like something ILMerge could help with.

If you don't want to give out framework - just don't. Provide only source you think is required. Otherwise most likely you'll need to either support both versions in the future OR never work/interact with these people (and people they know) again.
Don't forget that non-obfuscated .Net assemblies have IL in easily de-compilable form. It is often easier to use ILSpy/Reflector to read someone else code than looking at sources.
If the reason to provide code is some sort of inspection (even simply looking at the code) you'd better have semi-decent code. I would seriously consider throwing away tool if its code looks written in FORTRAN-style using C# ( http://www.nikhef.nl/~templon/fortran/fortran_style ).
Side note: I believe "nifty extensible frameworks" are one of the roots of "not invented here" syndrome - I'd be more worried about comments on the framework (like "this code is ##### because it does not use YYY pattern and spacing is wrong") than reuse.

How to protect my .net winforms assembly from customers of a customer

This question appears to have died, so I've decided to offer a bounty.
What I'm most interested in knowing is if my scenario in the ETA1 below is viable and is used. If it isn't, then a good explanation of why not would be a good answer. Another good answer would be an alternative (but not including the internalsvisibleto attribute).
The best answer would be, yes, it's viable, everyone does it and customers love it!
ETA2: I think I've thought of a good solution. I provide the customer with a distributable edition that is as functional as their edition but is unlicensed and has the classes and members hidden, using attributes.
I can do this with compiler directives, on every single important member, but I wondered if there was some global way to hide all members of a class?
A simplified scenario:-
I have a class that extends a control in someway and I want to sell my class under two licenses;
(1) Standard - The customer gets x number of controls that use my class but can't instantiate the class (its internal).
(2) Developer - The same as Standard except they can create their own controls that use my class.
My problem is that when the developer customer comes to sell their controls, they can't help but expose my class to all their customers.
--- Ignore this
The only way around it, in my scrambled mind, would be for the developer to somehow integrate my assembly into theirs, and in that way I can keep the constructor internal. Or, use the internals visible to attribute. / Ignore this ---
I'm sure someone here has had the same situation and any help would be greatly appreciated.
ETA1: I'm thinking aloud here, but, I could have a list of permissable calling assembly names which the customer could add to. When they ship their product, their customers' assemblies would not be in the list and therefore they wouldn't be able to instantiate certain classes. (The list could obviously be hashed).

I believe you will store the licensing information (i.e, Standard and Developer) somewhere in the registry. In such case, I suppose the simpler solution would be to implement LicenseManager. This is what most .NET component vendor use.
http://msdn.microsoft.com/en-us/library/fe8b1eh9.aspx
Hope this helps !

I believe you've come up with the only real solution, assuming the runtime will support it. As long as yours is a separate DLL, if the developers can instantiate your objects then so can anyone else, whether you try to hide it behind a constructor, a factory, whatever.
I wonder, though, whether consumers might not even be able to get around that restriction by integrating the shipped assembly into their own?

Why don't you use license keys? Your class reads the license key and depending on what permissions the license offers it disables methods at runtime?
The license key could be defined in the config file.

It's a tough one, just due to the nature of .NET. It's a shot in the dark, but you could look into products such as CodeVeil which provides assembly encryption at the IL level. Your assembly would essentially be shipped encrypted and the key would be handed to your customer. The customer would then be the only entity with the ability to decrypt your assembly instructions. Now, CodeVeil claims the following about its decryption keys:
Even though the key is stored in the application that does not make is insecure. In fact the key itself is not as important as the transformation of the data itself. CodeVeil also uses many runtime-protection operations to frustrate hackers attempting to capture the decrypted assembly. In addition CodeVeil uses a very special decryption system that decrypts only enough information for the .NET runtime to execute that specific method. The code is never stored in the same memory as the assembly itself so the decrypted code cannot be dumped to disk for analysis.
This is obviously a good thing, but this is the part you'd have to research because i am not familiar with the other techniques they use as part of their decryption algorithm. The cool thing about this is if it works, your customers will be happy and THEY can make their customers happy by exposing parts of your assembly through their own API. At the same time your code stays protected from tools such as ILDASM and Reflector.

Restricting using strong named dlls functionality

I'm trying to think of a way that prevents others from using your published dlls. For example let's say you create a cool lightweight WinUI photo processing tool that's separated into several assemblies. One of them is your precious filters.dll assembly that basically does all of the core filtering work. Once you publish your application, how can you prevent others from taking this filters.dll and using it in other projects?
I've already tried to look at the StrongNameIdentityPermissionAttribute which has a good example here but it doesn't seem to work for me, the code just works without throwing any security exceptions..
Any ideas?

Strong names have nothing to do with preventing or inhibiting reverse engineering. They only serve to stop people substituting assemblies with hacked versions - and only if people havent turned off strong name verification. There's nothing to stop people taking your code, ILDASMing or Reflectoring and re-ILASMing as they see fit.
InternalsVisibleTo and friends are on an honour system at the compiler level too, so not much use for what you're looking for (although for some obfuscators, internals get more agressively obfuscated than publics by default - though this can generally be overcome). My main concern here is to point out that jsut because something is 'internal' doesnt bestow on it any magic code protection pixie dust that stops reverse engineering.
Most of this stuff re why these sort of approaches arent a solution for code protection is summarised very well in this article
There are also code protection products on the market that go beyond obfuscation which sound like the tool for the job you describe.

One method that may work for you is to declare the the methods and classes in the filter assembly to be internal and explicitly specify the assemblies that can access it as "friends".
You do this with an assembly declaration (ususally in assemblyinfo) like:
[assembly:InternalsVisibleTo("cs_friend_assemblies_2")]
see Friend Assemblies for more info.
Also make sure you obfuscate the assembly or people can dig into the code with reflector.

Don't bother worrying too much about protecting your .NET code. If you deploy it to someone elses computer, and that person wants to use or read your code, they will.
If your code is valuable enough you need to keep it on a computer you control (such as a web server) and guard against unauthorised access.
Obfuscation will only slow determined people down. Strong naming and signing is not used to protect your code, but instead to ensure that the user can confirm the code originates from who they expect it to come from (ie ensure it hasn't been tampered with).