I am creating a Class LLibrary in c# by using microsoft provided Dll's.
Now i want to statically add those Microsoft provided libraries to My Dll.How can i do this.
I have simply added a reference to those Microsoft provided Dlls and creating My Dll? Is it fine or not?
if Microsoft provided dll is not available on other machine then my Dll may fails i need to add the libraries statically??
How can i do this??
There's no such thing as statically linking to another assembly in .NET. There are some third party products such as .NET linker that merge assemblies into one but they are unsupported.
If you have the redistribution license for that library, you can ship a copy along with your assembly. In Visual Studio you can make this happen by setting "Copy Local" to "True" in the properties window for that assembly reference.
See discussion here and read the comments -- Jeff does provide a way.
http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx
If the dll is not available at execution time; yes it will fail. However:
many Microsoft dlls are pre-installed with .NET (caveat: "client profile")
many of the Microsoft dlls are redistributable; so you can include them with your package
There isn't a linker provided in the core framework, although ILMerge may be useful.
Its not very clear what you want to achieve but it seems you are concerned that your class lib will work on some other machine or not. The thing is that the .Net framework is a free redistributable which should be installed if not present on the target machine. With the .Net framework already installed on a machine, there should be no problem as such.
Static linking as such does not make sense in .Net other that adding an assembly reference to your project. Hope it helps
Related
This is my first question. I have tried really hard to find a solution to my problem, but it seems to be a pretty specific collection of problems and I haven't found anything that works. I think I have narrowed down/identified my problem, but I don't know the solution or how to implement it correctly. I have tried to be detailed, but also concise. I don't have a strong coding theory background, just what I have learned online from MS documentation, Stack overflow, and other tutorial-like websites.
Background
In visual studio I wanted to create a class library that manages tables in a given database. It's part of a generic style API to handle implementations of repetitive database structures across projects. Because I wanted to create a generic class that I could use in various projects utilising various .NET frameworks, I decided to build the class using .NET standard 1.4. Because I needed to connect to MS SQL databases, I imported the System.Data.SqlClient namespace (an System.Data.Common) using NuGet.
I employed the use of a test MVC application in the solution and got some basic functions working in Visual Studio including opening the actual databases. Despite the recommendation not to, I referenced the compiled DLL from the release build rather than importing the reference as a project. I did this to mimic how I would be testing the class in my deploy environment. Everything here worked fine provided I added the reference to System.Data.SqlClient in the test application.
When testing the deployment however, things went awry. I was using an FTP connection to copy the files to the server. The server is running the .NET 4.5.2 framework. I kept getting a persistent error that the System.Data.SqlClient version 4.1 could not be found. I tried importing it into the project using NuGet and still had the problem. I was importing version 4.1, the earliest version (which is what I referenced in the class library). I also tried changing the reference in the class library to 4.4.2, the latest version, and importing that instead. Still had the same problem.
I then copied the code from the C# class from the class library and added it to a new .cs file in the FTP project- it compiled and ran without incident. I didn't need to import the System.Data.SqlClient in order to reference it, suggesting that a version of the namespace is already available on the server.
Problem/Question
This leads me to believe that there is a conflict where I'm trying to reference 2 different versions of System.Data.SqlClient within the FTP project.
As such, this leaves me to try and work out either:
How can I build a .NET standard class library that can use the latest installed version of System.Data.SqlClient in the target project (although, I fell like this is not really achievable given the way DLLs/versioning in general works)?
OR
How can I build a .NET standard class library that can use any of the currently available versions of System.Data.SqlClient (i.e. only use APIs that all current versions implement) and target the one already installed/referenced in the project that references it?
OR
How can I tell visual studio to include the referenced System.Data.SqlClient version used in my standard class library and only reference it for the purposes of running this library, with the rest of the project targeting whatever the other version may be?
OR
The otherwise correct way to manage this reference when it is not in the .NET standard library, but may be present in any given version in the application that references my library DLL.
Basically, I want to avoid having to write a new version of this class for every target framework if I don't have to.
End Note
I hope this question is of a good standard, I feel I have probably gone about something wrong in the implementation and that advice on the proper way to implement such a library would be of great help to myself and others in a similar situation.
I know that there are two GACs will be available on a system where latest .NET framework is installed.
i.e. "C:\Windows\assembly" for framework lower than 3.5, and "C:\Windows\Microsoft.NET\assembly\GAC_MSIL" for 4.0 and above.
Now, I have two questions:
First question is, I've a C#.NET assembly developed in frawework 4.5 and i have to add a reference to Microsoft.Office.Interop.InfoPath.Xml.dll.
I'm not finding this reference in the latest GAC, but it is there in the old one. So can I add from the old GAC?
Second question : If I install a latest version of Office, this reference also get migrated to another version. So unless I re-refer this dll in my project, my assembly cannot load the mentioned dll as it is checking for exact version number. Is there a generic solution for this, so that I need not change the reference and rebuild my application?
Remove the references to the GAC and use the assemblies from the file system. Set CopyLocal = TRUE;
You may need more than the one Assembly, an article here - InfoPath Interop describes the assemblies required.
The InfoPath primary interop assemblies can be downloaded here: http://msdn.microsoft.com/en-us/library/15s06t57.aspx
We are developing an add-in for Autodesk Inventor. Our software is a bunch of dll assemblies loaded into Inventor at runtime. We have decided to use the Microsoft Enterprise Library 5.0 for logging and exception handling.
Now we have a problem, because it turns out Inventor 2013 uses Enterprise Library 4.1. When our add-in is loading, it fails to load the proper version of an assembly, because Inventor already has an older version in its Bin directory.
Options we have considered so far:
During deployment of our product, overwrite the old libraries in Inventor's Bin folder
Use EL 4.1 in our assemblies
Both are bad and I'm running out of ideas, so I'm asking for help.
Option 1 raises this question: is the Enterprise Library backwards compatible and will replacing those DLL's in the Bin folder cause problems? I have tried it, Inventor doesn't complain and works as expected (haven't checked the EL functionality).
Option 2 makes us use the older version and binds us to the version Autodesk is using, so we would have to watch when they upgrade, especially when they release a new version of Inventor.
What is the best practice in this scenario?
UPDATE:
We solved this by just putting the newer version of Enterprise Library in GAC. I think what happened here was that .NET tried loading the older version first (because it was higher in assembly search order) and after failing never went any further to look for the proper version. When in GAC, it correctly resolves.
From what I can see, a reasonable solution would be to embed the assemblies and access them using the ResourceManager class, this would allow you to use the newer versions whilst maintaining the parent projects logging mechanism.
You might find this question useful:
Embedding assemblies inside another assembly
I'm new in monodevelop and I have a question.
I have some assemblies developed in Visual Studio 2010 in C# and I would like to use them with monotouch in Mac, my question is: do I have to use the source and generate the assemblies with monodevelop in Mac or just I need the assemblies and add them to my solution as a reference?
The framework profile used by MonoTouch was originally based on the Silverlight profile (aka 2.1) and was updated to include some, but not all, of the new API provided by the .NET framework 4.0.
As such you might be able to reuse assemblies, without recompiling them. That will depends if all the API are available, if you refer to assemblies not available in MonoTouch, under what profile (3.5 or 4.0) you're building the code...
However things would be a lot easier if you have the source code and are able to re-compile it inside MonoDevelop. That would provide you with debugging symbols (the .mdb files) also also catch, at compile time (not at run time), and fix code using any missing API (from MonoTouch).
You should be able to use the same assemblies as they are (no need for a recompile). If the assemblies depend on other nonstandard assemblies it might get tricky and you may have to deploy other assemblies along side the ones you want and then that may cause it's own problems if they are not open source or licenses are required to redistribute, etc.. Give it a shot, see what happens.
I have an application that utilises the BouncyCastle framework, how can I package this application so that I don't have to manually put BouncyCastle's .dll on others computers? I'm assuming that this can be done with an installer or something similar? Where do applications look for referenced third party libraries by default?
As an alternate approach, you can inject assemblies into your main assembly.
There are cemmercial tools that support this like DeepSea Obfuscator or you can use ilmerge.
The general way of working is that you develop using separate assemblies and when you ship the product you do an additional build step that merges assemblies into one big assembly. You can even internalize the injected assemblies so only your public interface is accessible.
This way you can deploy your product as a single assembly which is especially nice if you're building components.
To answer your second question; the .NET framework will look in a couple of locations. The GAC is dominant but if you make sure the referenced assembly is in the same folder as your main assembly .NET will find it. No need to register it in the GAC.
Since BouncyCastle is a managed library, if you create an installer project in Visual Studio and add your application's exe to it, the installer will automatically detect the dependency on BouncyCastle, and add it to the installer project. When users install your application, BouncyCastle's dlls will be automatically copied to the installation directory and everything will be good.
You need to create installer. Best one to start with is ClickOnce. It will give you ability to put all needed files into one and provide UI for installation.
Second question. The default place to look for assemblies is GAC.