Is it possible to split a method across two files in C#? I know partial methods are there, but they seemingly cannot do this.
Here's the scenario. I'm using an open-source library and need to add some customizations in one or more files. For example, I want to add two new fields to the class Employee and then initialize them in the InitializeFields() method of that class. Since the open-source project continues to evolve and new versions are released every now and then, I want to keep my customizations separate from the original project, to easily upgrade to newer versions of the library.
I have already split all the required classes into Orig.cs and Custom.cs using partial class syntax, and have added my custom fields in Custom.cs. Now the problem is that I have no way of splitting the InitializeFields() method, so that my custom code goes into Custom.cs file.
Please note that I cannot use inheritance to solve the problem. The open-source library would contain numerous references to Employee class and I cannot afford to change all of them.
When you do this, you're compiling the library yourself, right?
I understand you don't want to subclass Employee, because then all the library code that does new Employee() won't work. However, what if you rename Employee to EmployeeBase in Orig.cs, and provide the class Employee in Custom.cs? That way when the library code is compiled, new Employee() will reference your class, not the library one. Since you're compiling the library and your customizations in the same project, you can make this substitution.
Related
I am working on a WPF project using MVVM pattern. In solution, I have viewmodels,models,views and properties.As per requirment, I need to access the same classes(view models, models, properties) from another class library in same project. I do not want to add the reference to the class library as it is an exe file and a heavy component which has got so many classes which i do not require. So, is there any solution for this. How can i access same classes(view model,model,propeties) in a solution from another class library in same project?
Thanks & Regards
You have two choices. First one, is to refactor your exe in order to extract the reusable classes to a separate dll. Then, just add a reference to this new dll.
The other is to use reflection to access the members of the exe, which is the worst option, even worse than simply adding a reference to the big old exe.
I suggest breaking down your solution further in more projects, For example separate projects for Model, View and ViewModel or perhaps breaking down even further and then add reference only to the library you need. That way you are not exposing everything.
The other option is reflection which may be cumbersome to use and make your code ugly.
i am learning extension method, a very handy feature, which can save number of hours of coding, provides reusability. what i'm doing now a days, daily i'm creating 10 extension methods which useful in day to day scenario. but i'm not getting how to use these extension methods, everytime we need to add dll and reference it. or is there any smart way where we can use .
suppose
public static bool isValidMail(this string str)
{
Regex reg = new Regex(#"^[\w-\.]+#([\w-]+\.)+[\w-]{2,4}$");
return reg.IsMatch(str);
}
if i created 100 extension methods like this , then for every project should i need to reference this static class dll. as i work with multplie projects. is there any way that we can put these extension methods in centralized location or some assembly cache, where we can easily add using statement and get access to all static methods.
can we do like this ?
whenever we do create new project, can VS automatically add the extensionmethods which we created, so that in evey project we can access it. rather than adding dll everytime
i want to know how you people do.
i hope no one down votes it, just curious abt implementation of extension methods
It sounds like you should have a single project containing related extension methods - and then yes, you'll need to add a reference to that project from every project which needs it. That's a one-time cost. You could put it in the GAC, but personally I wouldn't - just treat it as another class library you need to depend on, like any other.
You could change the VS 2010 Project Templates to include a "Framework" DLL automatically.
visual studio templates
I simply keep a common repository of various common dll's and reference the ones I need, this is in SVN as well, I then have specific Snippets for each Framework I have created to make it easy to insert commonly used code.
I wrote some classes that I use with many different projects.
For example, I use Library.Controls.FlatButton.cs almost in every project.
The problem is when I add this as an "existing item"; the class gets created/copied in my soultion folder everytime. And each time I edit/update the contents of that class, I have to update all the Library.Controls.FlatButton.cs files in every project folder.
I need to be able to edit a single source of FlatButton class and when I compile/build a project (that uses the class file) gets updated to the new version of that class.
Question 1: Is there a way to do this?
I know that I can gather all these classes in a library project (Library.Controls) and add it to each application solution as a dependency.
Question 2: Is this the only way to work from a single source of common library files? And if I do; will all the classes in the Library.Controls namespace get compiled with every application, even if I've only used this FlatButton class in the project?
Hope this is clear for you..
thanks
I'd rather go with the approach of the shared library and add them as references to your client project.
If you don't want to do this. You could add the file as "Link". In Add existing item, select Add as Link instead.
Yes, a class library is the way to go and yes, since the whole class library will be referenced from your applications, all the classes will be available to it.
However, the fact that all the classes are available is not a bad thing, since they're in a separate class library it won't make your applications harder to understand (since the amount of code in those applications will stay the same), it might just be that you use up a little bit more hard drive space, though if you really worry about that you could put the class library in the GAC so that all apps reference the same copy of the library, though you'd better research this first to make sure that it's suitable for you.
Alternative way is to add FlatButton.cs file "As Link":
I have completed a student project, this project extract data from xml files on internet and save to database and displays it. And i use that data in a few different ways e.g. display on main page, in another tab as a table, and to create some graphs.
I did all this by making 5 different classes. Each class extracts different type of XML and save it to database with a single Load() function.
Last requirement of the project is to make the application Update-able/Patch-able (user does not need to download the whole new build to update the application, instead a small patch installer will add feature to application). How do i do that? My teacher says that adding polymorphism will help, a friend says that create different modules of application (break it into parts) so that each class will have its own dll.
What steps i need to do to make it patch-able? How to create dll of classes? how to break application into parts? Or all of this is unnecessary, i should just use a patching software that creates a patch by comparing both builds??
What you will want to do is follow the steps below:
Create new class projects in your solution, 1 for each of the classes you have.
Add a reference to your main project, 1 for each new project you created.
At this point everything should compile and like Henk said, if you don't change the public part of the assemblies, everything should be fine.
If you want to go a step further though, create a new interface and have the interface implement the methods in your classes. Have all your classes implement this interface. As long as the interface doesn't change, you can change anything you want about the assemblies and classes (as long as your classes keep implementing the interface)
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.