I am using Unity 3D engine. Its API is located in UnityEngine.dll.
Is there a way to block/forbid/make sure some of it's API methods can't be used? It contains some methods that shouldn't be used in my project by other team members even if they accidentally try to. Can this be done in C#?
UPDATE: I have no access to code of the library.
One thing to do could be offering your team members a facade DLL that will only expose the 'allowed' methods.
You might write some sort of analyzer that checks your scripts for forbidden API calls. Options:
Analyze the source code by iterating through all Assets of type MonoScript and identify rule violations using Regex tests (easy to implement as long as you are only looking for specific methods, but inaccurate)
Analyze the compiled code on IL level (accurate but tricky to implement)
You can then have this analyzer invoked automatically:
After every compilation by using DidReloadScripts attribute
After every build by using PostProcessBuildAttribute
I'm not sure if there's a way to make the build fail during post processing, but maybe throwing an Exception when a rule violation is detected will do it.
Related
Is this possible in C# to ensure that method/class have given signature.
For example I want to ensure that some method is public and static.
When isn't I want to this method red underlined.
I need it because I'm using this with component test runner app which uses reflection and expects public static bool methods from dlls. I want to force programmers to write public static bools component test methods. Is this a possibility to force them compile time? Or maybe force them build time by adding another simple app that checks it by reflection during post build event?
Is this possible? Maybe by method attributes? By reflection? But how?
Unfortunately, you cannot change/extend the C# compiler to achieve what you want here. However, there is a Microsoft project called Roslyn which exposes a public API for implementing your own extensions to the C# compiling pipeline.
Using Roslyn's structures, it should be easy to traverse your source code syntax trees looking for methods that are not public/static. Once you find them, you could generate a code issue reporting the problem; those issues are shown both in the code editor (wavy underline) and in the Errors List panel. From Roslyn's official documentation:
The code issue provider makes it easy to surface an error or suggestion to the user as a wavy underline in the editor or appear in the Error List window.
Look around for examples of CodeIssueProviders; it could be useful for what you need to do.
I want to log the entry of methods. In entry log I would have inputs\parameters received by the method. This has to be done for thousands of methods.
I thought of doing this logging of input parameters using C# ATTRIBUTES, since they fired before method call. (Something similar to ActionFilters in MVC)
Is that possible to read method parameters through attributes?
The concept you are looking for is called aspect oriented programming (AOP). It is a technique that allows you to "weave" in blocks of boilerplate code across your application code. Logging is a perfect example for that. You can either go the hard way and implement logging before and after each method call manually (which is on the one hand not feasible in large projects and on the other hand error prone).
Or you can use an AOP Framework that allows you to define these cross cutting functions in one place and apply it declaratively to your application code. There are several approaches to achieve this; one is to create IL after the build of the application logic and therefore integrating the aspects at compile time. A well known example for this is PostSharp. There also is a free edition that is good for the start.
BTW: PostSharp heavily relies on attributes, so you're on the right track.
Another option is to integrate the aspects at run time (keyword is interception). Most IoC Frameworks offer this. This approach is easy to use but has some downsides IMHO (weaker runtime Performance, only virtual methods can be intercepted).
Attributes are not 'fired before method call', the code that invokes a method that is decorated with an Attribute may (or may not) do something based on the presence of the Attribute.
The Attribute doesn't know the member it is applied on, nor can access it in any (straight forward) way.
I have a C# program where some parts of code are generated using D-style mixins (i.e., the body of the method is compiled, executed, and results inserted into a class). The method is marked with [MixinAttribute] and, naturally, I don't want it to be compiled into the program. Is there some cheap way of preventing the method decorated with this attribute from being included in a build?
The only way is with compiler conditionals:
#if DEBUG
[MixinAttribute]
// method you don't want included
#endif
The problem with this approach is that you then create a member which will be unavailable in builds where DEBUG is not defined. You then have to mark all usages with the conditional, and I don't think this is what you want. It's not quite clear but I think what you are really asking is how you create dynamic call sites at build time, or, rather, at JIT time (which is what the ConditionalAttribute controls). If this is the case, you can't really do this easily in C# without using some kind of dynamic dispatch overriding (using some proxying library) or by using some post-processing tool like PostSharp to manipulate the compiler output.
I am writing an application that allows the user to create custom algorithms for computing values over a collection of objects. Simply put, i will be having a string with the source code of class with one method.
The solution I have implemented is to compile the string source code in a separate dll for each such custom algorithm and then load them using Assembly.Load and instantiate the class saved in the dll. From a maintainability point of views, this means that i have to store the source code in the db (for example) and also manage the existence of the compiled dlls (recreate by compiling again the source code if it is missing)
Is there a better way to do this, considering the new features of .Net 4.0?
EDIT:
The input source code is C# and i am using CSharpCodeProvider to compile the code. The custom classes are all derived from a base class and they override the method that actually holds the computation logic. What i would really like to do is to get rid of the dll management and not lose (too much) performance in compiling all the classes every time my application starts up
I would look at scripting languages; IronPython is easy to embed, or there are JavaScript engines for .NET. Simple, and usually fast enough.
If (comments) you need to use c#, I would:
build all the current methods at the same time into one assembly; solves a lot of problems
if the data changes during execution, make use of AppDomains so that I can unload them
I've done something similar where the model/rules were XML, running it through a transform to get c#, and compiling with CSharpCodeProvider (or whatever); and simply polling every minute or so to see if a new build is required
The CSharpCodeProvider has been around for a while and should fit the ticket. It can be used to generate the separate libraries like you have been doing (perhaps you are using the CSharpCodeProvider), but it can also be used to generate dynamic class objects. If they all implement an interface you can cast the objects as an interface or you can use reflection to invoke your logic. Here is a codeproject article to achieve something similar:
http://www.codeproject.com/KB/dotnet/dynacodgen.aspx
I have a class that uses filesystem entities to manipulate data. We have several methods specifically designed to (attempt to) cope with some of the issues we face with this approach (file locking, non-existent files, etc.). Ideally I'd like to be able to issue a warning if another developer attempts access the filesystem directly via System.IO rather than using the helper methods.
Is this possible? The behaviour I'm looking for is to effectively mark methods such as File.ReadAllText() as if they were obsolete, but only within this project (NOT solution-wide).
I've done some digging around, and it looks like my only option is "tell them to make sure they use your methods". I'm hoping someone can give me a different, and more helpful answer. :)
--EDIT--
The suggestions of a custom StyleCop or FxCop rule are good, but unfortunately impractical in this scenario (not every developer in the department uses these excellent tools), and the legitimate methods that do the file access do use System.IO. Adding "ignore" attributes to the legit methods is a dangerous idea, too. If someone sees how I've "broken" my own rule, they'll likely copy the attribute to their own method.
Use a static analysis tool (such as StyleCop or FxCop) with a rule that captures "Do not use System.IO directly." Then integrate it as part of your automated build process and throw up if someone does try to use System.IO directly. No one likes to break the build.
You can write custom analysis rule for FxCop/Visual Studio Code Analysis and run these as part of your automated build.
Hmm. Not tried this myself, but how about forcing people to use your custom file handling classes, by using a namespace alias that "hides" the genuine System.IO. If I remember rightly these are applied at a project level.
Not sure if either of these suggestions are valid as I've never done them, but some food for thought:
Isn't this what "Enterprise Templates" are designed for? Don't they allow you to craft a policy file that restricts the allowed project references?
Alternatively, while not foolproof, could you add a pre-build event to the project that throws a warning if System.IO is referenced?
Can you add some custom functionality to a source-control commit hook? It won't find existing violations (if there are any) unless those files are changed but should detect new uses?
Any good?