Zlib Deflate in Visual Basic? - vb.net

So I'm trying to recreate and implement a section of code from a JavaScript file. I need to be able to use "Zlib.Deflate.compress" or something equivalent that will get me the exact same results.
I downloaded Zlib which included the .dll, 2 header files and a .lib file. but i cant figure out how to implement this into my application. I've tried to add it as a resource but i keep getting an error "A reference could not be added. Please make sure this file is accessible, and its a valid assembly or COM Component"
I tried using the method on http://msdn.microsoft.com/en-us/library/ms235636(v=vs.80).aspx to create a .dll file out of the header and .lib files, but that gave me a build error as well.
I don't know where to go from here.

Just use the native .NET DeflateStream class it should do exactly what you're looking for and doesn't require any third party libraries. Just the framework itself.

Related

I want to use c++ code on .net NanoFramework how can i do it?

I have created a library and i get a folder called Stubs
in this folder i get a bunch of files, how can i build it and used as an interrupt on the C# code?
There is a blog post with detailed explanations on how to use Interop in .NET nanoFramework. Please see here.
Look at section "Adding the Interop library to a nanoCLR image". You have to add those files and the respective CMakelists.txt to the project folder and build a new image that includes them.

How to bundle c++ dll files?

I am working on a Dot Net project and I am using C++ .dll files. I want the output of the program as just a single .exe file(which can easily be given to the customer) rather than multiple files. I have added those files under Properties>> Resources. However, when I tried adding them as Reference, I get the following error: Please make sure that the file is accessible and that is a valid assembly or COM component.
Is there a way to bundle these file into one without using 3rd party tools/extensions?
Plz advise.
Thanks in advance.

Reference VB.NET DLL in Kofax Document Validation Script

We are working on a validation script for Kofax Capture 9.0 / 10.0 in VB.NET 3.5.
We know how to create a script using the Admin Module, and how to get it operational.
The problem is that we need to reference a dll, located on a remote machine. (GAC is no option) This dll holds abstract classes we need in each validation script.
Even when putting the dlls locally (copy local), the Validation Module (index.exe) immediately throws the "cannot find reference" exception, even though the project compiled perfectly.
I guess the basic question comes down to: where do we put the dlls, in order for the Validation Module to find them?
The simple answer is to put the dll in the same folder as the application because this is one of the places which .NET will probe when trying to find it. The Validation module is run from the Capture bin directory which will be something like "C:\Program Files (x86)\Kofax\CaptureSS\ServLib\Bin\". This would need to be done on each client using Validation.
If you have a more complicated scenario, you could look implementing the AppDomain.AssemblyResolve Event and using Assembly.LoadFile to get the assembly from a custom location, but the using the bin path is less complicated.
If you end up having further trouble, you can troubleshoot by using the Assembly Binding Log Viewer (Fuslogvw.exe) which can tell you more details about why the assembly failed to load and where .NET tried to search for it. Assembly loading can fail for reasons other than just the path.
For more detail on how .NET loads assemblies, see the following:
How the Runtime Locates Assemblies
Locating the Assembly through Codebases or Probing
We found a solution: add all library files as "links" to the project. (Add --> Existing File --> small arrow next to "Add" --> Add as Link)
This ensures the files are compiled when you build the project. The Kofax Validation Module can now find the files, whereas when referencing the file, it could not. Why it could not, remains a mystery...

How to use FLTK 1.1 dll in MinGW?

I am trying to compile a project with MinGW that uses the fltk library. Whenever it gets to the file using fltk, it tells me "cannot find -lfltk".
I know it comes down to getting the .dll for the library and where I put it, but I am having a lot of trouble figuring this out. I found two files in the fltk folder named fltk.lib.dsp and fltkdll.dsp. I tried to just put these files in my system32 folder, but that did not work. I'm guessing thats because these are both VC++ 6 project files and not actually .dll and .lib files. I found this article:
http://www.fltk.org/articles.php?L372+I0+TFAQ+P1+Q
but I don't understand what it is saying.
you will need to define the FL_DLL preprocessor symbol to get the correct linkage commands embedded within the FLTK header files.
What does that mean? Do I need to #define something before my includes? How does this sentence translate into code?
If I am not on the right track please tell me. Any help is appreciated.
edit:
Also, I have my PATH variable set to C:\MinGW/bin/. I tried setting the files in there, but that did not work either. I know I have to do something to these .dsp files, but don't know what.
the error message is not related to dll.
it actually says that the linker library named 'libfltk.a' is not found.
so you should have that library first for compiling your program.

What exactly is the "Multi-threaded Debug DLL" Runtime Library option doing in VS 2008?

I have a solution in VS 2008 that creates a DLL. I then use that DLL in another application. If I go in to the DLL projects property pages and change the following configuration for a DEBUG build then the built dll no long provides the desired functionality. If I change it back and rebuild the DLL, then the DLL does provide the correct functionality:
Property Pages => Configuration Properties => C/C++ => Code Generation => Runtime Library
If set to "Multi-threaded Debug DLL (/MDd)"
then everything works as it should. I get the correct functionality from the DLL
If set to "Multi-threaded DLL (/MD)" then the DLL does not function properly...no runtime errors or anything, it just doesn't work (The DLL is supposed to plot some lines on a map but does not in this mode).
So the question is, why does using the /MDd flag result in correction functionality of the underlying code, while /MD results in incorrect functionality?
A little background...somebody else developed the DLL in C++ and I am using this DLL in a VB.net application.
All DLL's/debug code generation must match across everything that uses them. There may be another referenced library or object or dll or some code in there that is built using the wrong options; or specific options for an individual element that override the global project options.
The only way of figuring it out is to meticulously check all of the options for each file, checking the included and referenced libraries (.lib and .dll) and object files. Check the linker options too.
The reason why it doesn't work is probably because the debug version adds extra guard blocks around memory to allow detection of errors.
I had similar problems. My application which "used" a 3rd party DLL crashed when its runtime library was set to "Multi-threaded DLL (/MD)", but worked when its runtime library was set to "Multi-threaded Debug DLL (/MDd)".
It has something to do with passing std::strings and std::lists across the DLL interface.
Our guess was the low level definition of these types was somehow different in the two runtime libraries.
We solved our related problems using this rule...
The DLL and the DLL user must be build using the exact same runtime library.
The main difference between the two options is in the libraries that your code will be linked at later. for the debug version for example this will include LIBCMTD.LIB and a few others. if your library is going to be built as debug the you should always link with MDd. failing to do so will result in lots of unresolved external linker errors at best. and sometimes the code compiles normally but crashes at runtime. if this happens in vb.net then a catch can easily hide the error. I guess you should make sure you build setting is correct. for more detailed information check this.