I have found a math parser Here. I have never added something like this to a program and was wondering what I need to do to add thing like this to a program. For example I want to know where to put the file and how to call it in the headers so that I can use the classes inside the file. I looking for general instructions that can be applied to other things as well.
Sounds like you have come from a bit of a C background. C# is a little different in the way that we pull in external code, and its actually quite a bit easier than C.
To reference some code using Visual Studio, you will need to add a reference to that dll. once you have the dll included (via a reference) in your project you can use it in your code by adding a using statement and then instantiating objects from that library
MSDN docs around this are here: http://msdn.microsoft.com/en-us/library/wkze6zky.aspx
EDIT:
if you are outside of VS as you have specified there's a few things you will need to do:
Let your compiler know where the assembly is so that it can correctly link
Add the assembly to your running directory (it should sit alongside your executable)
OR add your library to the GAC
OR manually load it with an Assembly.Load call
Related
I have a bundle of helper-method packed into an own class library (i.e. Tools.dll). When I start a new project I almost everytime reference this library.
When Visual Studio compiles my new project I get a bunch of files in the bin\debug-folder. Of course there are "mynewproject.exe" and "Tools.dll" but since the helper-methods have own references I also find "HtmlAgilityPack.dll", "Scintilla.dll" etc. wheter I really used some of these functionalities or not.
My question is: Can I get rid of them?
If Visual Studio can filter them out themself, perfekt, if I have to do it manually at runtime, can you offer me an idea how to do that?
I did a lot of research but I can't find a method to analyse which dlls are used or to analyse at runtime which method calls which helper-method.
Thanks a lot!
Update to specify my idea:
My idea was to run a script every time the program is started which checks which dll-files are there and then runs recursive through all methods to look which files are really needed. Then I could delete the unused dll-files. If that script needs to long I could additionally add a flag so this script has only to run once after every compiling.
If anyone has a better idea I'm of course interested :)
You can use my Runtime Flow tool to get this information. In the Runtime Summary window you will see all assemblies, classes and methods used during the program execution. And for each method you will see how it was called.
I am not sure the best way to explain this so please leave comments if you do not understand.
Basically, I have a few libraries for various tasks to work with different programs - notification is just one example.
Now, I am building a new program, and I want it to be as lightweight as possible. Whilst I would like to include my notification engine, I do not think many people would actually use its functionality, so, I would rather not include it by default - just as an optional download.
How would I program this?
With unmanaged Dlls and P/Invoke, I can basically wrap the whole lot in a try/catch loop, but I am not sure about the managed version.
So far, the best way I can think of is to check if the DLL file exists upon startup then set a field bool or similar, and every time I would like a notification to be fired, I could do an if/check the bool and fire...
I have seen from the debug window that DLL files are only loaded as they are needed. The program would obviously compile as all components will be visible to the project, but would it run on the end users machine without the DLL?
More importantly, is there a better way of doing this?
I would ideally like to have nothing about notifications in my application and somehow have it so that if the DLL file is downloaded, it adds this functionality externally. It really is not the end of the world to have a few extra bytes calling notification("blabla"); (or similar), but I am thinking a lot further down the line when I have much bigger intentions and just want to know best practices for this sort of thing.
I do not think many people would
actually use its functionality, so, I
would rather not include it by default
- just as an optional download.
Such things are typically described as plugins (or add-ons, or extensions).
Since .NET 4, the standard way to do that is with the Managed Exensibility Framework. It is included in the framework as the System.ComponentModel.Composition assembly and namespace. To get started, it is best to read the MSDN article and the MEF programming guide.
You can use System.Reflection.Assembly and its LoadFile method to dynamically load a DLL. You can then use the methods in Assembly to get Classes, types etc. embedded in the DLL and call them.
If you just check if the .dll exists or load every .dll in a plugin directory you can get what you want.
To your question if the program will run on the user's machine without the dlls already being present - yes , the program would run. As long as you dont do something that needs the runtime to load the classes defined in the dll , it does not matter if the dll is missing from the machine. To the aspect you are looking for regarding loading the dll on demand , I think you are well of using some sort of a configuration and Reflection ( either directly or by some IoC strategy. )
Try to load the plugin at startup.
Instead of checking a boolean all over the place, you can create a delegate field for the notification and initialize it to a no-op function. If loading the plugin succeeds, assign the delegate to the plugin implementation. Then everywhere the event occurs can just call the delegate, without worrying about the fact that the plugin might or might not be available.
I have an SSIS (2012) package which has 16 (c#) script tasks so far and there will be more. I am frustrated at having to basically copy code in for each component. I have a .cs file which I add to each script task but as this is copied into the dtsx if I update the 'common' code I have to modify every other component which has contains it.
I have tried to create an external assembly so I can put it into the GAC and avoid this stupidity but I cannot get it to work - the problem seems to be that my common code requires a reference to the InheritedVariableDispenser to work. I have tried adding references to Microsoft.SqlServer.Dts.Runtime in the external assembly in order to handle this but as I say, this fails.
A partial solution would be to create a customised script task with my common routines pre-loaded but this doesn't seem possible either.
My last alternative option is to write a program which acts directly upon the dtsx file and modifies the xml to update all the section which incorporate the common code. While this appeals to the hacker in me it does some like a little too much work and a bit 'iffy' - it would only solve the update problem while still not allowing re-use in another package.
If anybody knows how to re-use code which references SSIS objects I would be most interested!
Does your common code really require access to the full VariableDispenser object, or just to the variables?
If you only need the variables themselves, then I'd suggest putting the common code in the external assembly. Use script components to consume the common code functionality; e.g.:
var foo = new MyLogic();
Dts.Variables["TransmogrifyResult"].Value = foo.Transmogrify(Dts.Variables["AnInput"].Value, Dts.Variables["AnotherInput"].Value);
If you absolutely must have access to the VariableDispenser itself, the MSDN VariableDispenser documentation warns that you may actually need to use an IDTSVariableDispenser100 instead.
I'd like to create my own auto-"Resolve" feature. In VS, when you right-click and choose "Resolve", it gives you options and upon selecting one, it adds the necessary "using ..." statement to that file.
I'd like to take it 2 steps further:
I want to parse the text when there are changes to look for any references that might be needed, rather than underlining and waiting for the user to "Resolve".
I want to not only provide a "using ..." statement, but also figure out which DLL to reference in the project. In VS, you only get "Resolve" if you already have the correct library referenced already.
Now, to keep the complexity down:
I only care about built-in .NET libraries that ship with C#/VS/.NET.
I know there are a few cases where even the .NET classes overlap (e.g. Timer in System.Threading and System.Windows.Forms), but they're the exception.
So, my question is, is there some list/mapping I can grab that maps all the .NET classes to a "using ..." statement and a library reference (including standard file path)? Or, is there some way for me to automatically generate such a list?
you can look for 3rd party products that provides this. there is a great product ReSharper on the market that builds symbol data base from source code files (not from compiled code) which is also fast and optimized. It DOES allow you to resolve the symbol and add a reference to the assembly if it already knows this assembly from other projects in the solution. I believe it's not the only product.
Building the list of classes from system assemblies is not that hard. Simply make the list of system assemblies from standard install, load each of them and create list of public classes. Look at System.Reflection.Assembly methods, such as Load() and GetTypes()
I think you can list the DLLs in GAC, and use reflection to list all the public classes for each DLL.
This way you can create a mapping, and figure out which reference to add and which using statement to add.
I want to create a single dll that is merged with a 3rd party dll. This means end consumers will only have to deal with 1 dll instead of 2.
For augments sake lets say that the 3rd party dll is nLog. How do I deal with cases where the consumer of the merged dll already has NLog as a reference in their project?
Ideally what I would like to be able to do is change NLog namespace within my project to "XyzNLog", meaning that the user wouldn't need to do any aliasing... Any idea how I might do this?
Now I know I can add aliases to my project for NLog so that I have to refer to it as XyzNLog, but I want the same to carry over to consumers of the merged dll so that there is never a conflict.
UPDATE - Solution
http://blog.mattbrailsford.com/2010/12/10/avoiding-dependency-conflicts-using-ilmerge/
Bingo! So by using ILMerge, it becomes
possible to merge the third-party
libraries DLLs in with the Providers
own DLL, meaning we will only have one
DLL to deploy. But that’s not all, we
can actually go one step further, and
tell ILMerge to internalize all
dependencies. What this does it
converts all the third party classes
to be declared as internal, meaning
they can only be used from within the
final DLL. Woo hoo! problem solved =)
Given this the problem where the consumer of my dll could also have NLog goes away... as my referenced NLog shifts to being all internal! This is exactly what I want.
Does anyone have any feedback or thoughts on this?
I agree with Hans, I would strongly suggest releasing with registering the DLLs separately.
Otherwise, you could be in DLL hell which would drive your consumers away.
You could then devise some clever deploy methods to detect if the DLL is already registered, etc.
I have to agree with #Hans Passant (and here's some info about the oft-discussed DLL hell), but since you've asked the question, I'll try to answer it.
You can bundle the third-party DLL as a resource. Please see this question for details.
As far as your other questions, I'd just expose the relevant classes from a third-party DLL under your own namespace, and maybe use extension methods to provide whatever additional functionality you want.
For instance, you can provide access to NLog's Log() method using a static method in your class, say XyzNLog.Logger.Log(), taking care of initialization, and whatever else internally, inside your code (static constructor or whatever else you fancy up).
Since you load the NLog assembly using the method above, you'll be the only one having access to the embedded NLog assembly directly and the user won't be able to access it. Now, you don't get the benefit of having all classes autoexposed from NLog, you still have to expose them manually in this case.
EDIT: Another approach would be to try to use ILMerge with /internalize flag as described here. You may not be able to completely resolve the issue, but look at this article to see if you can avoid the pitfalls the author described. Spoiler alert: it's not all peaches'n'cream on this one either, but it may work, with enough extra effort.