A legacy VB6 app I maintain has dependencies on some third-party DLLs. DLL information (from embedded metadata) is pasted below.
I am looking for any pointers to documentation, a current vendor who supports these DLLs, or any tribal knowledge at all about what they do.
Related
We are developing audio plugins which are dynamic libraries. This made it very hard to use 3rd-party libraries such as Qt, as our product DLL would search for Qt's DLL on host DAW program's executable directory, and it is impossible to install our dependent DLLs to that position (you don't know which host will be used, and host may even be installed later than the plugin).
I've made some brief search on this problem, the few answers direct me to a Microsoft technology called side-by-side assembly, and I'm almost drawn in the huge documentation and concepts on that. So my question is:
How to make my DLL to load several specific dependent DLLs located at path_to_plugin/MyPlugin_dependents/xxx.dll?
Or is there any examples to side-by-side assembly that simply do this and is much simpler than the official example?
I have a piece of code that compiles for both the Silverlight and the .NET targets. It depends on Json.NET and SharpZipLib. My goal is to make a portable library that Silverlight and .NET projects can both link against.
Since there is no version of SharpZipLib targeting "portable-net40+sl50", I have a problem.
However, if I knew how, I would be willing to write the wrapper code myself.
So: How can I write a portable library that depends on Silverlight's SharpZipLib when being linked against from Silverlight and depends on .NET's SharpZipLib when being linked against from .NET?
Is that at all possible or is that something only Microsoft can do?
If your code uses a limited sub-set of the SharpZipLib API, you could create a "dummy" PCL library comprising this API subset, but without any functionality implemented.
What you then must do is to change the strong name (assembly name and signing) and version of the existing .NET and Silverlight SharpZipLib:s to be the same as your "dummy" PCL SharpZipLib and re-compile the platform specific libraries as well.
With this set of assemblies (PCL, .NET and Silverlight) you will now be able to consume the PCL library from other PCL libraries. In a platform specific application that makes use of PCL libraries that in turn consumes the SharpZipLib library, you should explicitly reference the platform specific SharpZipLib library that has the same strong name and version as the PCL analogue.
You should find more about this technique ("bait-and-switch") here and here. The PCL Storage project is also a good example of where this technique has been applied.
I am am considering installing a dll assembly in the GAC and I don't have enough experience to know if this is the best practice for this scenario. Hopefully someone here can shed some light on me and get me pointed in the right direction.
The Scenario:
I have a library assembly that I have written. This DLL is designed to read some data from an output file of a third party software package. Once read the data is available for access to the caller of this DLL.
My company has developed four different windows form applications that use this library file to get data into the apps.
The 3rd party software manufacture has change the the way they write their output file, so I have modified my DLL to support the new features the third party is using.
Currently all the apps have been written using the dll as a private assembly.
The Update:
To update all of the applications would require a rebuild of all four apps referencing the updated dll file, then reinstall all four apps on every machine that may be running them.
If I were to change the dll to a GAC assembly, then all I would have to do is reinstall the updated dll in the GAC assemble on every machine that uses the DLL assembly.
The later option seems to be simpler, then the next time this happens, we just update the one dll in the GAC and away we go.
The Question
What is the best practice here?
This link makes me think I should not be thinking about GAC
When should I deploy my assemblies into the GAC?
And if GAC is the answer how do you go about deploying the strong named assembly so that is installed in the GAC from the setup file?
Any help is appreciated,
Mike
I have a set of utility LabVIEW VIs that make calls to a custom DLL written in C++. I'd like to package the VIs into a LabVIEW toolkit and deploy it via an installer, but am unsure about the standard practices involved in doing this where a custom DLL is involved. I've looked at VIPM for packaging the VIs, but so far I haven't found a way to generate a package and include the appropriate DLL dependencies. What is the correct way to go about generating an installer for a LabVIEW Toolkit and installing the DLL dependency for said toolkit in the correct location (where ever that may be)?
The DLLs immediately known to the system - i.e., the ones entered in the CLFN node - are added automatically.
DLLs which are used indirectly and DLLs which are determined programmatically cannot be auto-included and must be added manually to the Source files section of the respective Build rule.
I am a .NET developer, and in the .NET world finding out which assemblies are referenced by an assembly is easy:
I can inspect the assembly using many available tools to see the assemblies it references.
This does not cover cases where assemblies are loaded dynamically somehow, but still gives some estimate.
Is there a similar process for native DLLs? Can i take a dll and find out which DLLs it uses ?
I am using a native COM library, however i am not sure which components (DLLs) should be redistributed with my own application. This information is not found in the documentation of this library as well (QC OTA API).