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.
Related
When I compile a project in VB i get the following files:
<ProjectName>.exe
<ProjectName>.exe.config
<ProjectName>.pdb
<ProjectName>.vshost.exe
<ProjectName>.vshost.exe.config
<ProjectName>.vshost.exe.manifest
A quick search of them all gives info about them holding information of debugdata and such. But how do they help me? Do you guys ever use these files?
Let's say I'll make a program and send it away to a friend, what is recommended to send? Just the .exe file or something more?
Your project output (here the exe, but could be a DLL if the project type is a library for exemple) and the config files are needed to use the program, plus any dependency you could use in your project (external libraries for example)
The pdb and vshost files are used by your programs for debug, not directly by yourself. And they are only generated in the debug configuration (edit: can also be generated in release, depending on your configuration).
More SO questions about those files: see ClickRick links in comments & other links:
About PDB:
What's the PDB file?
How do I use PDB files
About VSHOST files:
What is the purpose of the vshost.exe file?
http://geekswithblogs.net/pavelka/archive/2006/08/11/WhatIsTheVshostExeDoing.aspx
You can find everything explained here:
What is the purpose of the vshost.exe file?
To quote Daniel Brückner:
.exe - the 'normal' executable
.vshost.exe - a special version of the executable to aid debuging; see
MSDN for details
.pdb - the Program Data Base with debug symbols
.vshost.exe.manifest - a kind of configuration file containing mostly
dependencies on libraries
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.
I have a project with two targets, one is a Cocoa Static Library, the other is the accompanying test project. Despite building the main project in different ways over and over again, I cannot find the .a file that I expect it to produce.
In fact, I cannot find the build folder associated with the project. I need to link to the library in an app, but cannot do so if I can't find the file to link to.
These properties are correctly set:
(Build Products Path) SYMROOT = build
(Intermediate Build Files Path) OBJROOT = $(SYMROOT)
All tests pass (which means the code MUST be building right?)
Breaking the code causes the build to break - again suggesting that it is building.
Also, the "Products > libproject.a" file is red in the xcode project navigation
I also checked the DerivedData directory, but all the seems to get created is the objects fot the OCunit stuff. Still no .a file against which I can link.
Where is my .a file?
Any help would be much appreciated.
It's probably in ~/Library/Developer/Xcode/DerivedData/ somewhere.
i did a build in vb.net and got one exe file
however, when a user runs the file, it says it is missing one of the libraries (itextsharp).
so the question is, if there is actually a build option in vb.net, why does it not include the library in the same exe file?
You can distribute the iTextSharp DLL with your application. The easiest way to do this is to simply include it in the same folder as your EXE. The DLL should be output to your Project's Debug/Release folder each time you build assuming you've added it as a Reference in your project and the Reference's 'Copy Local' property is set to True.
If you want to distribute one EXE and include the iTextSharp in that, you can use the ILMerge tool (or alternately Gilma from SourceForge) after you build your EXE.
in the properties for the reference set the Copy To Output to Always
ITextSharp is not a library linked in your project output; it's an assembly referenced by your project output. And while VB.Net builds one executable from your source code, the CLR still needs all the referenced assemblies in the same folder as your executable.
To make everything work, you can distribute ITextSharp assemblies along with your app. Alternatively, if you indeed need only one file, you can use ILMerge on your project output and the assemblies you want included. However, you might need to determine all the correct assemblies you need merged. I wouldn't revommend using this tool, unless you understand how it works.
Note: If you want to use ILMerge with .Net v4.0, read this page.
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.