In C++, you can create usable code modules by creating a class, and giving out header and implementation files to the developers who want to use your class.
I want to do this in C# but I have little experience with the C# language. Basically I need to create a class that can be reused by another C# programmer in Visual Studio 2010. I know that referencing DLLs is one way to use other peoples' classes. Do I need to create a DLL to achieve what I want to accomplish? Or are there other, better ways?
For example, let's say I create a Cow class that can "moo". In C++, someone who uses my class would just include Cow.h, instantiate a Cow object myCow, and then call myCow.moo(). How can I achieve this simple task in C#?
Thanks for your time and patience.
Yes, just create Class Library project and share the resulted dll's.
Other developers will just need to add a reference to your dll and after that they're free to use any public objects from your library.
It is the standard to create a dll to distribute reusable code.
You could look into old school COM objects, but I would steer clear of them and just use a well organized class library.
Of course you can always share your source files, but the recommended .Net way of distributing reusable code is though dlls. This allows developers using any .Net language to use your code (they don't have to use the same language as your project).
It also makes it easier to maintain the project. If you share source code then it will likely be more difficult to distribute updates than if you just needed to update a single dll. If you have multiple projects referencing the same dll, they can all reference it from the same location and whenever the dll is updated, all the projects that use it will automatically use the updated dll the next time they compile the project. You can also update the dll without having to recompile the projects that use it (though you can't change the names/signatures of anything that is being used by the project).
Related
I have a DLL written in C# for which I don't have the sources. I have tried different C# decompiler to modify the DLL, but they all give me errors in my attempts to recompile with the modifications, I suppose due to IL decompilation limitations. Is it possible to add a .cs file to the root of the DLL in order or inject a method to add a functionality ?
PS: This is not intended to hack a software but to create a mod of a game which requires DLL modification.
Your best approach may be to just create a wrapper project around the dll to add the functionality that you want. Your code could them reference the project instead of the dll. As long as the classes aren't sealed you should be able to inherit from them.
Modifying code you don't have access to probably isn't a good idea to begin with. Especially if the dll could be updated in the future.
You can also create a new DLL with the same namespace. This might make things look as if they're in the same location, but it's not the best practice and it could be confusing since namespaces are expected to match the project/dll name.
Benjamin's solution with the wrapper seems reasonable.
The Reflexil plugin for .NET Reflector could inject a method or a class in a DLL as illustrate in a video by its creator.
It prevents decompilation-compilation errors as it just injects IL code in the assembly.
To install this plugin follow these steps.
for my C# projects, I created a "Helper-Project" that handles some common issues, which I use in my other projects. For the specific solution, I include my "Helper-Project" and use the public classes defined within.
In my "Helper-Project", I referenced some external libraries, which I want to use in my specific working-project (that includes the "Helper-Project") as well. Is there a way to access those referenced libraries of the "Helper-Project" from the "Working-Project" as well, or do I have to include them in the "Working-Project" as well?
Here is schematic display of the structure:
solution
working-project
helper-project
references
library-that-I-want-to-use-in-working-project-as-well
Thanks in advance,
Frank
You will have to reference them in the working project.
If for some reason you absolutely cannot reference those libraries in the working project and the methods you need from the libraries are few, you can (but shouldn't) create wrapper methods in the helper project:
string wrapperMethod() {
return libraryMethod();
}
There are a lot of variables and methods in my program and I want to seperate some of them in other class files. But as the program grows the methods and functions can change.
I searched on the net but many people generally speaking for dll files. Without making a dll file, how can I arrange my code and split into small class files?
Yes, just split it out in to a separate file in a new class but still inside the same project. The term for what you are doing is called Code Refactoring. There are some tools built in to Visual Studio to make it easier to do, and there are some 3rd party tools that add even more features to make it easier to do.
But all it boils down to is just making new classes in the same project and referencing those new classes from where you took the code out from.
You can add folders to your solution. Classes are by default a namespaceprovider, so that classes in this folder have a different namespace.
For example if your default-namespace is MyNameSpace and you create a folder called Entity then all classes in this folder have the namespace MyNameSpace.Entity
And all Items in a project are compiled to one single dll or exe
Just add more classes to the project and put the data and behavior (methods) into the appropriate classes. The project will still build into a single exe or dll.
Generally, it's better to add a second project under the same solution call it "CommonLib" or something like that. Then you add it as a reference to the main application and set up the project so that the applications build depends on the libraries build. Add a using statement for the common lib where ever you want to use those objects. This is definitely better for large scale or enterprise applications. There's a pretty decent chance that somewhere down the line you'll want to reuse some of this code, if everything builds into a single exe that won't be an option.
When I need to add a reference towards a library, I've always been told to use the "add existing project" method, and referencing the project itself inside my solution.
But here in my new company, the use another method. They have a server which holds the compiled dll's, and keep versions of them so they can reference older versions when a change is too important to refactor older apps.
While I find this system really complicated (I guess there is a lot of work if a program pointing an older version of the dll is updated and needs some changes in this dll), they seem to find it pretty convenient.
What are the best practices for this? Linking the dll directly? Linking the project? And why? Any information is welcome!
Thanks in advance !
I usually take a copy of the compiled dll (if the source project is not available or if I don't need the source) and put it in a folder inside my solution, and then reference that. I check it in to source control along with my project.
I am of the opinion that you should be able to check out a project and build it directly from source control without having to go hunting dlls etc.
The Add existing project method is useful when you want to reference a library project which is develop side by side and you want to test/use it's types and methods and this (Add existing project) method will not be used to add the reference of pre-compiled (dll) files.
Read Project Reference (MSDN) article.
You would include it as a Project when you want to simultaneously work on the library. And that would happen mostly for small(ish) libs that will be distributed with your program (bin folder).
When an assembly is (going to be) installed in the GAC, and thus has its own release cycle, it makes more sense to reference the binary only.
Several combination of the above are possible too.
Adding Compiled dlls is mainly when the code is more or less locked (Architecture level code ) which you hardly ever changes
eg
1) communication layer(remoting/wcf)
2) Generic Gui layer (Wizards/dialog boxes)
3) Security layer (azman stuff)
you only need to change when your product is going to another direction say it uses to use .net remoting as communication now it will be using WCF
Using projects as reference when you are frequently changes referenced projects
also Visual studio works out nicely order of building the projects.
Although your company's approach is probably not very common among Microsoft developers, it is used rather successfully in the Java world. In the long run it is probably better controlled than any alternative, but without a fair amount of support scripts/programs (which, for instance, update projects/solutions automatically when needed) it can easily become unmanageable. In the Java world it is directly supported by tools such as Maven.
Honestly, I can't word my question any better without describing it.
I have a base project (with all its glory, dlls, resources etc) which is a CMS.
I need to use this project as a base for othe custom bake projects.
This base project is to be maintained and updated among all custom bake projects.
I use subversion (Collabnet and Tortise SVN)
I have two questions:
1 - Can I use subversion to share the base project among other projects
What I mean here is can I "Checkout" the base project into another "Checked Out" project and have both update and commit seperatley. So, to paint a picture, let's say I am working on a custom project and I modify the core/base prject in some way (which I know will suit the others) can I then commit those changes and upon doing so when I update the base project in the other "Checked out" resources will it pull the changes? In short, I would like not to have to manually deploy updated core files whenever I make changes into each seperate project.
2 - If I create a custom file (let's say an webcontrol or aspx page etc) can I have it compile seperatley from the base project
Another tricky one to explain. When I publish my web application it creates DLLs based on the namespaces of projects attached to it. So I may have a number of DLLs including the "Website's" namespace DLL, which could simply be website. I want to be able to make a seperate, custom, control which does not compile into those DLLs as the custom files should not rely on those DLLS to run. Is it as simple to set a seperate namespace for those files like CustomFiles.ProjectName for example?
Think of the whole idea as adding modules to the .NET project, I don't want the module's code in any of the core DLLs but I do need for module to be able to access the core dlls.
(There is no need for the core project to access the module code as it should be one way only in theory, though I reckon it woould not be possible anyway without using JSON/SOAP or something like that, maybe I am wrong.)
I want to create a pluggable environment much like that of Joomla/Wordpress as since PHP generally doesn't have to be compiled first I see this is the reason why all this is possible/easy. The idea is to allow pluggable themes, modules etc etc.
(I haven't tried simply adding .NET themes after compile/publish but I am assuming this is possible anyway? OR does the compiler need to reference items in the files?)
UPDATE (16/05/2010):
I posted a similar question with a little more detail for question 2 on Experts-Exchange. I don't want to post all that info here as it just will be too messy but it explains question 2 in greater detail.
For your first question, you want to use svn externals. More details can be found here: http://svnbook.red-bean.com/en/1.0/ch07s03.html
For your second question, you need to create a seperate assembly and the easiest way is to create a new project within your solution. You can't have a single project emit 2 dll's (that I know of)
For your first question:
If the base project is a library then there is nothing stopping you from creating the following directory structure on your SVN:
Base project
Cool project nr 1
Cool project nr 2
All projects built on the Base project will include a relative reference and then everybody can checkout his Cool project X and the Base project and work on them. Checking-in changes for Base project will allow everybody else to see them by updating their Base project image. Advantage: only one SVN trunk required.
For your second question :
I tried my best, but I can't understand what you're asking :).