Develop Reference

Best way to make methods easily callable and configurable by third party

I have a solution with several self-contained classes and methods. For example, I have:
a FileDownloader class that has multiple different methods that download files based on passing in a URL or multiple URLs
a DataTransformations class that has multiple methods that transform data depending on what is necessary for a given operation
a FileWriter class that writes some data to some kind of file type or file format
etc.
I have all of these classes as .cs files under the same solution. I can consider the order of executions for some specific operation and call the methods from MAIN in the correct order and it produces the output that I expect. I will eventually, however, need to call some or all of these methods in many different configurations for several different processes and I don't know how to do that. I know how to pass in configuration through command line arguments, but even that requires the specific order and number of methods called stays the same between processes. This is not tenable because I will not need to download files in some instances and I will not need to transform data in some instances etc. I am very new to .NET development and I have not yet wrapped my head around how to truly decouple these classes from each other. Do I have to deploy a different solution for each class? I would like to just be able to say "call file downloader with these parameters" and then "perform data transformations based on these parameters" basically like steps in an execution job.

Dirty Answer, Compile as a library and then add a reference in whatever project you want to use those methods for. you can then call the methods by name (LibraryName).MethodName(Parameters). of course you will need to always have that DLL in whatever other project need access. if you have any questions on how to do this let me know.

C# Attribute to detect unused methods

Is it possible to write an Attribute that can track methods to detect if those methods are never called?
[Track]
void MyMethod(){
}
output:
warning: method "MyMethod" in "MyClass" has no references in code.
It is not strictly necessary to have it run at compile time, but it should work when the application is initialized (better at compile time anyway).
This tag will be putted to track methods on Audio Library, since audio is refactored very frequently and we usually search for audio methods with 0 references in code we want to mark these methods so we can detect quickly and remove unused audio assets.
Basically each time we add a new sound effect, we may later no longer trigger it (calling its method), and the audio file/playback code can remain in the application for a long time.

Maybe this is the answer you're looking for?
Finding all references to a method with Roslyn
you can use the code there to automate something of your own with Reflection I'd say

A partial answer is found here:
C# reflection and finding all references
I can use that info to get references to methods marked with a particular attribute, however that is a run-time script (But better than nothing).

A little late, but better than never: I use WinGrep by Gnu to search all folders and files for the name of the method:
`C:\>grep -irw "method_name" * --include=*.cs --include=*.sql --include=*.txt`
You can include as many, or as few, file name extensions as makes sense for you. In the example above, I show the top directory as C:, but you can start the search at any directory that makes sense.
The huge advantage of using grep over IDE based searches is that it will search across multiple projects and solutions.

Coding style with generics and inheritance [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How to name C# source files for generic classes
We are currently re-evaluating how we do generic classes when we inherit from a general class. Currently we will put the following two class definitions in the same file
class Foo
{
// code for class
}
class Foo<T> : foo
{
// code for class
}
My question is a simple one, should we keep them in the same file, or split them into separate files?
So far the pros to keeping them in the same file is that you have all the code there right infront of you. The con is that when both classes get sufficiently large, it could become un-readable.
What I would like is good reasons as to why we should do one or the other. If you recommend separate file, I would also like you to include possible naming conventions, or a strategy to get around the fact that we can have only one file named Foo

This is a matter of opinion, but I'd keep them in the same file rather than try to maintain some naming convention for one or the other.
While I subscribe to one class, one file, I think there is value in having these together. We really treat these as one class, right? Typically, Foo will be abstract, and is just a way of using our generic types… well, more generically -- in places where the type parameters don't matter and can't be known at compile time.
If the classes become too large, it should be a red flag anyway that some responsibilities should be broken out.

Unless classes are utterly trivial, I never put more than one in a single file. It's much easier, IMO, to find exactly the class you seek when you have a predictable, unique file name, with namespaces based on folders, generally.
For naming your files, maybe this:
foo.cs
foo_t.cs
foo_tuv.cs // for a foo class with three generics

I'd recommend keeping the classes in the same file. It makes it easier to locate all Foo classes. Also, with code folding (regions) you can easily view only a single class by collapsing the other.
That said, I wouldn't say either way is wrong. In the end this is one of those things that will take some experience to come up with your personal preference and find what works for you in your particular project. And you may find that what works well for one project doesn't necessarily work for your next project.

Answered here:
I think the common solution to this problem is to name the file like
this:
{ClassName}`{NumberOfGenericParameters}
This would give you this filename:
Bag.cs and Bag`1.cs
This is the way Microsoft handle this issue in frameworks like Asp.net
Mvc.

Keep these classes small and you can keep them in one file. If you can't keep them small, divide them. If you prefer keeping them in separate files, it's okay too. But keep them small anyway. In case of separate file, I would use FooGeneric name but someone here How to name C# source files for generic classes recommends Foo`1 (for 1 parameter).

How to organise large code files?

I am increasingly aware that my code in any single file can often span hundreds of lines quite easily and although I know the implementation might be sound, it still feels messy and unorganised.
I understand that there are situations where a lot of code is neccessary, but whats the best way to organise it all?
I've thought about separating variables from methods, privates from publics and internals but I don't want to because I can't help thinking that the components of ONE class belong in ONE file.
This whole thing is compounded when I'm working with the codebehind of a WPF window, which always seem to grow at an exponential rate into one huge mess very quickly.
Also: C# has a keyword called partial, which allows you to split a class over any number of files without affecting the functionality. However, I have noticed that Microsoft only seem to use partial to hide generated code from you (Winforms / WPF.) Which leads me to question whether splitting a class simply because it has many lines is a legitimate use of partial - is it?
Thanks

Separate your code into responsibilities. For each responsibility, define a single type. That is, follow the Single Responsibility Principal. Doing so will result in smaller units of code, each of which performs a very specific function. Not only does this result in smaller files, but also in better design and maintainability.

If your files are big because they contain a single class/struct that is big, then this is usually (but not always) a hint that your class is dealing with multiple concerns and can be refactored into a number of smaller, more specialised classes.

If I understand you, your main problem is that your forms end up being too big, which leads to the classes for those forms containing too much code, which is quite normal if your forms aren't very simple. The way to try minimize this is by using User Controls since if you move the controls to other classes, you also move the code behind to other classes.
It can sometimes make it a little more difficult to communicate between the controls, but that's usually more than made up for by the fact that the code in each class will be much easier to understand.

I tend to group properties, constructors, methods, and helper methods (private methods) together with regions. If I have a lot of methods, I create more regions based on what they do (especially good for overloads). And speaking of overloads, try minimizing your code with optional parameters.
As far as I understand partial means that the class exists in two separate files. Webforms and controls are partial because the other "part" of the file is the as[p|c]x file that goes with it.

I go on the theory that if you cant see an entire method on one screen (i.e. you have to scroll), you should break the method up into further methods - either in the same class or when the code will get used more than once into a helper class.

We use stylecop. It helps a bit because it enforces a structure on your code and an order for what should appear where. Hence you can then find your way around larger files a bit more intuitively.

To improve code readability: you can use the region block: https://msdn.microsoft.com/en-us/library/9a1ybwek.aspx . As for improving the structure and design of your code - consult some specialist books.

C# code re-use via namespaces

I like to create a file full of custom functions which I have made, which I may use in another project or something. Now I don't fully understand how to go about this, normally in a language like php, you'd just create the php file and then go include("cust_lib.php") or whatever the file is called.
Now I think that the process involves the library having its own namespace, then either go using custom_lib; or custom_lib:: within the script (I don't want to get into a discussion over which is the best way to go here).
Is this right? Or should I create the library and convert it to a .dll, if so how do I go about this, what sort of syntax does a dll have inside it etc.
However if its just file within one project then I don't need to go down that route do I? I can just create the namespace and use that?
This is what I'm working for at the moment, and thought it would be something like this
namespace Custom_Lib{
~~functions to go here~~
}
However the functions have to exist within a class don't they? So that becomes something like
namespace Custom_Lib{
class custom_lib{
public string function1(string input){
return input;
}
}
}
So some help, pointers, examples would be appreciated so I can wrap my head around this
Thanks,
Psy.
(Yes I call them functions, that just comes from a long php/js etc background)

The normal approach would be to create a Class Library project, put your classes and methods in that project, making sure that those you want to expose are public. Then you add a reference to the resulting dll file in the client projects and you will have the functionality from the class library available to you.
Even if you decide to put it all into one single file, I would still recommend you to make it a class library since I imagine that will make it easier to maintain. For instance, consider the following scenarios:
You decide to put it in a file and include a copy of that file in all projects where you want to use it. Later you find a bug in the code. Now you will have a number of copies of the file in which to correct the bug.
You decide to put it in a file and include that same file in all projects. Now, if you want to change some behaviour in it, you will alter the behavior for all projects using it.
In those two cases, keeping it as a separate project will facilitate things for you:
You will have only one copy of the code to maintain
You can decide whether or not to update the dll used by a certain project when you make updates to the class library.
Regarding the syntax issues: yes all methods must exist within a class. However, if the class is merely a container of the methods, you can make it (and the methods static):
public static class CustomLib
{
public static string GetSomethingInteresting(int input)
{
// your code here...
}
}
That way you will not need to create an instance of CustomLib, but can just call the method:
string meaningOfLife = CustomLib.GetSomethingInteresting(42);

In addition to Fredrik Mörk's well-written and spot-on response, I'd add this:
Avoid creating a single class that is a kitchen-sink collection of functions/methods.
Instead, group related methods into smaller classes so that it's easier for you and consumers of your library to find the functionality they want. Also, if your library makes use of class-level variables, you can limit their scope.
Further, if you decide later on to add threading capabilities to your library, or if your library is used in a multi-threaded application, static methods will likely become a nightmare for you. This is a serious concern, and shouldn't be overlooked.

There no question here. You answered it yourself. Yes, you have to construct a class to include all helper methods. And yes, you can either compile it to a dll if you want to reuse in multiple projects it or just add the source file to the project.
Usually I declare the helper class and all functions as static to avoid initiating the class each time I use it.