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.
Related
I have an independent solution with multiple projects including class libraries and control libraries. This solution and all its projects are under TFS source control.
I reference the output of one or more of these libraries in all new projects I develop. References are currently binary rather than project references.
The new projects are also always under source control and now I need to add debugging support for the libraries.
If I reference the library projects from them, the project file is modified and no longer works with the original library solution since source control providers for the library and referencee may be different.
Is there an easy way to accommodate this?
You should package the shared binaries, along with indexed PDB's, into a Nuget package. Nuget was specifically designed to solve these problems.
You can index your PDB's by running an indexing tool. TF Build can automatically index your PDB's.
Nope.
There are some strategies you can use, however. Easiest (possibly, but not in some cases) is to build the project you wish to debug, drop the binaries on top of the application that hosts them, and attach your debugger to the running application. This makes sure you have the correct version of the assembly under debug, but you might have to do unwanted things, such as making sure you're not targeting a specific version of the assembly
Which may be bad news for an assembly under development. It also requires lots of handiwork, which depending on where your application runs may require you run remote debugging, deal with issues transmitting dlls across untrusted networks, etc etc.
I just am trying to replicate my distributed C# project structure to WIX setup projects. Now there is the following problem:
LIB: a C# library solution that builds AnyCPU .NET dlls from several C# projects
APP: the dlls from LIB are referenced (as file references) by this main application solution. Additionally there are platform dependent libs included in this application solution, therefore it is important to being able to create setups for the two specific target platforms x86 and x64.
Now I started to create a wixsetup project within the APP solution (which works fine). Then I proceeded with creating a wixlib within the LIB solution that references the LIB .NET dlls into the wixlib.
Now the problem:
The wixlib references the AnyCPU .NET dlls within a DirectoryRef which seems to be platform specificly tagged when creating the wixlib. Therefore I have to go back to the LIB solution, build the project with one platform target, copy the built files (via SVN externals mechanisms) to the APP solution, build this project with the exact same target platform as the wixlib was created with and repeat this procedure for creating the other platform.
It may seem that this is kind of complicated, but doable. Due to the fact that I omitted several other library solutions for which the same problem applies and the fact that all those libraries are used in multiple application solutions and - finally - everything has to run on our build server automatically as well, it is clear that this will not work.
I know of the following solution, though:
Double the .NET dll references within wixlib to assign them to different DirectoryRef INSTALLDIR and INSTALLDIR32 e. g. and to implement those different directory references in the wixsetup.
But this would complicate things as well and is not my preferred solution therefore - if there is an alternative.
If there is no smart alternative, just tell me and I will do things as described in the last paragraph.
I am using a third party dll file which is referenced within a visual studio project using C#. In previous experiences on other projects, I was able to load objects from different dlls using dllImport, then create objects as if the source code of the dll was included in my project. However, that method is not working with the 3rd part dll. The program works flawlessly on the computer I am programming it on, however, when I run it on a different computer, it cannot find the dll. Is there a method to include the dll compiling and avoid using dynamic linking?
The default setting of .NET Framework is to load native libraries from system paths, not current directory.
But you might learn from System.Data.SQLite project (open source), so as to pre-loading native libraries from current folder, and based on OS bitness,
http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
Although generating a mixed mode assembly (native and managed bits are merged) sounds like a better solution, System.Data.SQLite users often are confused. Thus, I recommend the pre-loading approach.
I have created a backup console application (this is 32bit program running on .net 3.5 on windows 8 64bit) with these dlls:
Delimon.Win32.IO,
SevenZipSharp,
7z(native) dll
I have tried to merge them with ilmerge but program still asks dlls( Delimon.Win32.IO not found ) while startup.
Then I tried second solution:
add dll's to resources & handle AssemblyResolve event, still same problem.
Any clue what is problem?.
I dont want any commercial solution.
I'd recommend using Costura.
https://github.com/Fody/Costura
Costura is avaliable on NuGet and is a simple solution for providing a custom AssemblyResolve system. It will take all your projects references and automatically add them at build time.
Also, if you have native or mixed-mode assemblies (like for example 7zip) then you'll need to provide Costura with a bit of configuration. Everything is covered in the readme.
I have an external compiled assembly with HtmlHelper extension methods. I need to use it in the project so that there wouldn't be any absolute references to this assembly because the project is shared with Team Foundation Server. What is the usual way to solve the problem?
I usually have a lib folder that is part of the solution and which contains all third party assemblies used by the projects. As it is part of the solution it is version controlled by TFS. Also when you distribute the solution it will contain all the necessary references that are needed to build making it independent.