I would like to know how can I embedd a code source file (if possible), something like that:
class X
{
include "ClassXsource"
}
My second question - Can I build DLL or something like that for my colleagues to use? I need them to be able to call methods from my "part" but do not modify or view their content. Basically just use namespace "MyNamespace" and call its methods, but I have never done anything like that.
Thanks
The C# compiler does not support include files. You can of course use a pre-compiler, that would read your source code files, and insert the included files into them, before passing the new files to the compiler.
As for producing a class library, sure. You can do it in two ways:
You can make the project source code available, so that they would add the project with all its files into their own project, and thus compile your class library as part of their solution.
You can compile it yourself, which produces an assembly file on disk (YourClassLibrary.dll), and then give that file to your co-workers. They would then add a reference to the file and can start using it.
You can't, except by using some external preprocessor. You could use T4, which is already used by Microsoft as a text templating tool, e.g. for code generation with the Entity Framework; see this MSDN documentation page.
With T4, you would include another source file like this:
<## include file="c:\test.txt" #>
Now to the more fundamental point: Including source files is not how you usually create libraries, especially not in .NET. What you would do is define one or more types containing the functionality—there are no global functions in C#, the closest you can get are static methods. You would then compile this and give the resulting assembly (.dll file) to your colleagues. (Or you create a NuGet package and publish it to a source that your colleagues can access.) They will be able to load it as a reference into their .NET project and use your class.
public static class MyFunctions
{
public static void MyMethod1(...) { ... }
public static int MyMethod2(...) { ... }
...
}
(Of course such code is more procedural than good object-oriented design, but this may or may not be an issue for you.)
No, not in that way. But you can create a class library and put all classes they need to use there. They simply add a reference to that dll from their project and import the namespace, voila, they can use the classes.
Related
I have a couple of functions which I would like to add to DLL. I found this programming guide How to: Create and Use C# DLLs (C# Programming Guide). It's very short and looks like a really simple thing to do but I've noticed that each single function added to dll is enlosed in a separate file, separate class and functions are static. Is it always the case? What if I have a couple of overloaded functions, such as:
public void WaitForTheKey(object o = null) {}
public void WaitForTheKey(string message, bool addlines = true, int[] quantity = null) {}
private void _WaitForTheKey(string, bool, int[]) {}
Shall I put them in separate files like in the tutorial? Thanks.
EDIT.
If projects for DLL do not require separate classes and files, what would be the reason an author of the tutorial followed this theme?
Thanks
First of all you should keep you logic split by functionality. So all these methods you should keep in one class (in most cases it means one file).
It is very simple to create dll. If you use Visual Studio you should pick Class Library project type and then simply build it. As a result you will get dll file. Or use compiler directly from command prompt like it was shown in tutorial.
You are overthinking it; the tutorial is just an arbitrary example.
Simply structure the code in a way that makes sense, with as many or few classes as you like. Everything that is public in your assembly (classes, methods, properties, fields, events etc.) can be accessed by the consumer of the DLL.
I have a class named CreateListView in my project in a .cs file and I am able to use it by including it's namespace in my usings at the top of my page. Is there a way I can compile the file so that I can still use the class but users are not able to see the contents of the class. I want the users to still be able to create objects from that class but I don't want them to modify it and it will also be better if they could not see it.
You can put it in a separate project (Class Library), compile it as a DLL and give others the binary to use in their projects.
As others have said, you want to compile it into a Class Library, and then distribute the resulting DLL. If you really don't want them to be able to see into it with a tool like Reflector, then you should also consider using an obfuscator.
You would want to place the code in a seperate project and then build it and give them the .dll this will allow them to use the class you've created but not see the code.
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.
I have to make a graphical user interface application using the language of my choice. The application will run on Windows XP. It will be some sort of a complex windows form application.
I think and as per most suggestions, C# will be the best to use.
The tree structure on the left of the GUI will populate after reading from a configuration file which will be a binary file . (but initially I can work with a simple ASCII file to test my code.). The application will accept some inputs from the user through this GUI and will write the back to the same config file and will reflect the changes in the tree structure or the labels or any other pertaining field on the form.
There will be 3 tabs and 3 corresponding config files for each of the tabs.
I need some help designing the application for now. I am planning to make a host application (main application) and use the 3 tab controls as plugins. Is this workable ? If so can you please guide me on this. I mean how do I make 3 plugins in C# and how do I write the interfaces so that the main application knows which plugin to load and when to load it ? Will there be a separate “Plugin” folder under my project folder ? I hope you got my point though this is too little of an information for you to begin with.
Also there are some .cpp files already existing in the project. These files along with some .h files contain some important definitions and constants in them. These need to be integrated with my C# application. I have no clue how to do that but I am sure that it is possible by compiling the .cpp code in a .dll and then exposing the compiled .dll to my C# application. Please let me know if you need some more information for the top level design.
Thanks,
Viren
To implement a plugin interface manually, you will need a method something like this. I've left some TODOs in, where you would want to enhance the error handling and/or make the implementation a little more case specific.
public List<T> LoadPlugin<T>(string directory)
{
Type interfaceType = typeof(T);
List<T> implementations = new List<T>();
//TODO: perform checks to ensure type is valid
foreach (var file in System.IO.Directory.GetFiles(directory))
{
//TODO: add proper file handling here and limit files to check
//try/catch added in place of ensure files are not .dll
try
{
foreach (var type in System.Reflection.Assembly.LoadFile(file).GetTypes())
{
if (interfaceType.IsAssignableFrom(type) && interfaceType != type)
{
//found class that implements interface
//TODO: perform additional checks to ensure any
//requirements not specified in interface
//ex: ensure type is a class, check for default constructor, etc
T instance = (T)Activator.CreateInstance(type);
implementations.Add(instance);
}
}
}
catch { }
}
return implementations;
}
Example to call:
List<IPlugin> plugins = LoadPlugin<IPlugin>(path);
As for the c++ part of your question. There are few different ways you could approach this, though the correct choice depends on your specific situation. You can make a clr compliant .dll in c++, which your c# project could reference and call like any other .dll it references. Additionally, you could use P/Invoke to call into a native .dll.
One of the easiest plugin concepts I have ever used was certainly the Managed Extensibility Framework which will be part of .NET 4 (afaik). Unfortunately it is not yet finished and only a preview is available which may differ from the final version. That being said, we used MEF Preview 3 for a uni project and it worked without problems and it certainly made the whole plugin stuff a lot easier.
Look at the System.Addin namespace :
http://msdn.microsoft.com/en-us/library/system.addin.aspx
Otherwise you can do everything yourself. Before this namespace was available, I used a common interface "IPlugin" that every plugin/addin needed to use. I then had a loader which inspected all the *.dll in a folder then used reflection to check for the interface. I could then create instances of classes which implemented my plugin/addin interface
The cpp files will probably need converting to c#, or you could possibly create a dll to reference.
Take a look to Castle.
.NET Framework use COM model in its guts. See http://blog.caljacobson.com/2007/07/26/creating-a-plug-in-framework-in-c-resources/ for a list of plugin example using this techique.
Hope I'm asking this correctly:
I have a project
Projects.Client
I have my class library ( infrastructure stuff I use all the time )
Library
Assuming these are both projects, how can I do this from a class in the "Projects.Client"
using Library;
public class xxx
{
public void DoSomething()
{
Library.SomeDll.DoSomething();
}
}
SomeDll.dll is referenced in the "Library" project. "Library" is a reference in end client project "Projects.Client"
I know I could simply add SomeDll to the "Projects.Client" project but there are a number of items and I use them all the time. I'd like to be able to include the "Library" and somehow be able to reference everything within it(including raw code and dll's). Is this possible?
please note: I'd prefer not to write explicit wrappers for all the methods and the dll is static so I can not seem to get away with doing this in the "Library" project:
public static class WrapSomeDll
{
public static extern SomeDll Dll();
}
Any inventive answers are appreciated, I might not even need dual references, wrappers e.t.c.
Sorry, that doesn't work. You need the reference to SomeDll in order to use its metadata in Project.Client. It's really as simple as that.
Keep in mind that references aren't just a matter of resolving symbols to addresses. This is a matter of pulling over the metadata (types) so that it can be used.
You just need to reference the project and add using clauses for the namespaces you want to use. There is no need to specify the name of the DLL