I'm curious to know how to wrap up some 3rd party exe files into my dll for deployment.
At the moment we rely on the deployed system having the 3rd party software installed and our wrapper exposes their console app to our MVC application.
Ideally I'd like the wrapper and the exe's all packaged up together in a nice bundle that can be deployed anywhere regardless of the 3rd party app being installed.
Any advice on where to store the exe files in my application would also be really helpful. I'm curently dropping them into the bin.
I'm aware that licencing can be an issue here and it's something I'm already ontop of.
By "packaging" you mean including the .exe file in your dll? I mean you could of course include the .exe file into your setup package, but that's not what you want if I understand correctly.
I believe starting a .exe file which does not physically exist ist not possible in windows. But you could include the .exe file as a ressource into your .dll.... possibly in a compressed form. When you need it, it could be dropped into a temporary directory, executed, and deleted after use or on dll uninitialization.
However this technique could maybe alert some security software...
Related
When importing dlls in Visual Studio (VS2017) I have to choose the path where the dll file is. If I move the dlls file later, or I share the project, reference will be broken.
I can see there is a COM option where you can see system DLLs plus some libraries from installed software.
How can I create a set of dll files (SDK) so I can see them there?
At this moment, I'm creating a lib folder in the solution directory where I put all my dlls, so I can import them easily and share the project including libraries.
The idea is that every developer must install an SDK with all these libraries in order to use them, and add them without having to copy files. It might make lib updates easier for us.
Also, when deploying the proyject solution will every user need the SDK installed? I guess I have to mark the library for local copy.
(new to .NET) I've built a small console application that uses a 3rd party data access component for Oracle (assemblies: devart.data.dll and devart.data.oracle.dll). I've been asked to gather environmental requirements for a new test server. On my local machine, I am able to simply copy the bin/debug or bin/release folder and my app just works. However, I doubt this will be the case on a new system. Obviously, I know I'll need the .NET 4.5 framework. But for this other dependency, I don't see these dlls in my folder. I'm not even sure how these were installed (I inherited this computer from a now-gone developer).
How do installations of 3rd party tools typically work with respect to deployments? How will I be able to say what's required and how to get it on the target machine? Any advice is much appreciated!
Have you checked your project references to see if the dlls are referenced in the project. If they are, you should be able to see the path they are located in. I'm guessing the dlls are on your network drive somewhere and your project is pointing to them.
You should be able to check all your references by right clicking on your project and selecting the "add reference" item on the menu. If the ddls are on your network drive, as long as the testing server has access to the file directory, you shouldn't need to worry about deploying the dlls.
In my VS2012 project I use a third party dll. I do not add it into project references, but I have added its path into environment system variables (in Path), as suggested into the user manual of the third party software.
So inside my project I don't have any references to that dll, but only a .cs file where there are some [DllImport("xxx.dll")].
In the same solution, I've created an InstallShield project, to create a setup for my application. When I run the setup, I notice that the dll is copied into my application folder. That is not good for me, because if I try to run my application I have some compatibility problem with other dlls of the third party software.
If I remove manually the xxx.dll from my application folder, it works correctly.
So, how can I avoid that xxx.dll is copied inside the application folder?
Turn off any of the "magic" options so that you can control exactly what files you install. For example, set.NET Scan at Build to Properties instead of Dependencies and Properties.
My application needs an Oracle .dll which I deploy into the bin folder of the application along with the rest, and it works fine.
But what I want to do is to avoid deploying the library, so I need the server to know where to look for it. I added the .dll into C:\Oracle\bin, a path which is included at Path system variable. But it can't find the assembly if it's not into the application's bin folder.
Any hints, please?
This is pretty much have things work. You have discovered 2 viable deployment options. 1) Bundle it in your applications bin directory or 2) Install the oracle network protocol correctly and using the install API.
There are really only 2 more options that I can think of. 1) Statically link with the necessary network libraries -- I don't recall ever seeing these available on Windows, I know I have used static linking to OCI libraries on Unix, been a long time ago though. 2) Host the Oracle connectivity in a middle tier and have you deployed application always make calls to your middle tier (instead of direct Oracle calls)
BTW, you probably do not want to use the OCI libraries, ugly code compared to the modern ways of doing it.
If you go into the reference properties for the dll that you are trying to add you can change the Copy Local property to False.
This will allow for the program to pull the dll from the original location that you found the dll in.
The only thing that you have to watch out for is that your dll is in the same location on your dev PC as it is on your Server if it isn't your program will not find your dll. an example of this is if the dll on your server is in C:\Oracle\bin it must be at C:\Oracle\bin on your dev PC.
What exactly is needed for someone to use my C# windows application in executable form? I do know that .NET framework has to be installed on the computer, but I heard there is much more. And is there any way to spread the application besides doing installable form via "Publish"? I mean, which project files are needed? Only exe file, or these pdb and manifest files too? Do they have to be from bin/debug or bin/Release, or makes no difference? (I know files created with this application are saved in "debug") Because I need to show my program (as exe) to certain person with .NET framework...
You only really need the .NET framework, unless you've used third party components.
If you use a Package and Deployment project in your solution it will automatically generate a .msi file for you with everything that your app needs to be installed.
You need .pdb files if you want file and line number detail in any exceptions thrown by your app. If you're selling the app as a product, don't include them as that information poses a security risk. If it's an internal app, then consider including them in your package and deployment project, because it's useful information to get with exception logs.
For runtime etc, .NET should be enough. Or with some tools (like as is used via MonoTouch and some others), not even that.
For the application, just the exe is necessary, but there can be lots of other required files - a config file perhaps, or maybe supporting non-CLR dlls (third party dlls perhaps).
For deployment, you can just use the exe etc (xcopy deployment), or ClickOnce (.application), or an installer (.exe / .msi).
The best option is to give them the files from your bin/release folder.
PDB files (which you should only find in your debug folder) contain the symbols for debugging your application, so you don't need to give them those.
There are other options such as ClickOnce deployment or an MSI, but it sounds like you just need to temporarily show this to only one individual, so it won't be worth it to go down this path.
In short, as long as the user has the correct version of the .NET framework installed on their machine, and you give them all of the relevant files from your bin/release folder (the EXE file, any additional DLLs that your application references, and any miscellaneous files like an app.config file), they should be able to run it just fine.