I have developed a C/C++ based Windows Runtime Component for Universal Windows, and I am now trying to include it in a NuGet plackage.
With NuGet version 3, the runtimes folder has been introduced, see here for details. Unfortunately, this documentation does not give much information on how to deal with Windows Runtime Components.
I have organized the files in the NuGet package like this:
└───MyNuGetPackage
├───lib
│ └───uap
│ MyRuntimeLibrary.winmd
│
├───build
│ └───uap
│ MyNuGetPackage.targets
│
└───runtimes
├───win10-x86
│ └───native
│ MyRuntimeLibrary.dll
│
├───win10-x64
│ └───native
│ MyRuntimeLibrary.dll
│
└───win10-arm
└───native
MyRuntimeLibrary.dll
The MyNuGetPackage.targets file is used in the build procedure to add a reference to the .winmd file and explicitly specify the implementation .dll:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="InjectReference" BeforeTargets="ResolveAssemblyReferences">
<ItemGroup Condition=" '$(Platform)' == 'x86' or '$(Platform)' == 'x64' or '$(Platform)' == 'ARM'">
<Reference Include="Dicom.Imaging.Codec">
<HintPath>$(MSBuildThisFileDirectory)..\..\lib\uap\MyRuntimeLibrary.winmd</HintPath>
<Implementation>MyRuntimeLibrary.dll</Implementation>
</Reference>
</ItemGroup>
</Target>
</Project>
As far as I have been able to tell, this NuGet package composition works; the relevant implementation file is selected when building for the different platforms x86, x64 and ARM.
However, with the above approach, I am only including the .winmd file from one target platform (x86 in this specific case). Is this really OK? It seems to work, but is really the .winmd file platform independent?
In case the .winmd file is platform dependent, I have tried to add platform target specific .winmd files under the runtimes folder, like this:
└───runtimes
├───win10-x86
│ └───lib
│ └───uap
│ MyRuntimeLibrary.winmd
│ └───native
│ MyRuntimeLibrary.dll
and I have updated the MyNuGetPackage.targets file accordingly. However, when I install this alternative NuGet package and try to build for a specific platform, I get a payload build error that the MyRuntimeLibrary.winmd file is being copied to the output directory from two separate locations, both the lib\uap folder and the runtimes sub-folder.
It also does not help to exclude the top lib\uap folder altogether; if I do, the build procedure does not find any .winmd file reference at all.
If the .winmd file is platform dependent after all, how should I organize the .winmd and .dll files in my NuGet package to ensure that the package installs sufficiently on all platforms?
It probably helps to understand what a .winmd file really is. It is a reformulation of the COM type libraries of old, you might have run into a .tlb file before. Might have looked at its content before with the OleView.exe SDK utility, File + View Typelib command.
Much the same as .NET metadata, your profile says you definitely used them before. Files you find back in the References node of a C# project. You might have looked at them before with ildasm.exe or a .NET decompiler like Reflector or ILSpy. Or the IDE's Go To Declaration command. You already know that such references are platform independent.
Microsoft retired the .tlb file format and replaced it with the .NET metadata file format. A format that was flexible enough to also express COM declarations. And expandable enough to express WinRT declarations, the kind that could not be hammered into the .tlb format. Like generics and attributes, heavily used by the language projection to make COM client code easier to write. Pretty good move, Microsoft had to do very little work to change existing tooling, like the C# compiler, to work with .winmd files.
Long story short, it behaves just like .NET assemblies and COM type libraries at compile-time. The compiler uses it to retrieve type declarations. You can make it platform dependent by accident, like using int when you meant to use IntPtr. But the language projection you'd use in whatever language you program in makes this a very rare accident. And quickly discovered when you test.
Related
I have a compiled assembly (dll) and a corresponding xml document (generated by DoxyGen, I think?). How can I convince MonoDevelop to take me to the definitions within the xml document instead of the Assembly Browser when I use Go To Definition?
I've tried putting the xml file in the same folder as the dll, but that doesn't seem to be enough, and the MonoDevelop documentation doesn't seem to mention this at all.
I want to add a csv response template to the default slingshot/search? web script which is inside in a jar (Alfresco remote api).
Already l have an ant script which build a jar inside Alfresco/tomcat/shared/lib
Inside this jar l have define an extension xml file config/alfresco/site-data/extensions/extension-modules.xml
<extension>
<modules>
<module>
<id>Custom DocumentList Widget</id>
<description>Extend Alfresco Search</description>
<customizations>
<customization>
<targetPackageRoot>org.alfresco.slingshot.search
</targetPackageRoot>
<sourcePackageRoot>webscripts.search</sourcePackageRoot>
</customization>
</customizations>
</module>
</modules>
</extension>
Also lnside config/webscripts/search l have the search.get.csv.ftl file but I never get the csv response. Is this the best way to modify/extend the default web script ?
No this isn't the best way to extend this in your case.
Normally it is, but in your case just use the default override mechanism of Alfresco.
So just place your addition in org/alfresco/slingshot/search, cause Alfresco doesn't has a csv.ftl file, so it will be available.
The extension module is uses to extend/change the default get.js & get.html.ftl file, so I'm not sure if it will accept any addition if you don't specify the one of the above files.
I'm writing a simple Erlang program that requests an URL and parses the response as JSON.
To do that, I need to use a Library called Jiffy. I downloaded and compiled it, and now i have a .beam file along with a .app file. My question is: How do I use it? How do I include this library in my program?. I cannot understand why I can't find an answer on the web for something that must be very crucial.
Erlang has an include syntax, but receives a .hrl file.
Thanks!
You don't need to include the file in your project. In Erlang, it is at run time that the code will try to find any function. So the module you are using must be in the search path of the VM which run your code at the point you need it, that's all.
For this you can add files to your path when you start erlang: erl -pa your/path/to/beam (it exists also -pz see erlang doc)
Note that it is also possible to modify the path from the application itself using code:add_path(Dir).
You should have a look to the OTP way to build applications in erlang documentation or Learn You Some Erlang, and also look at Rebar a tool that helps you to manage erlang application (for example starting with rebar or rebar wiki)
To add to Pascal's answer, yes Erlang will search for your files at runtime and you can add extra paths as command line arguments.
However, when you build a project of a scale that you are including other libraries, you should be building an Erlang application. This normally entails using rebar.
When using rebar, your app should have a deps/ directory. To include jiffy in your project, it is easiest to simply clone the repo into deps/jiffy. That is all that needs to be done for you to do something like jiffy:decode(Data) in your project.
Additionally, you can specify additional include files in your rebar.config file by adding extra lines {erl_opts, [{i, "./Some/path/to/file"}]}.. rebar will then look for file.so using that path.
What's the difference between libs and src folders?
The source folder is for ActionScript and Flex source files, mostly with .mxml or .as extensions. Anything you code you put in the src folder, though if you create your own library of reusable code, you might keep it in a second source folder (with another name, of course).
The libs folder is a special folder in Flash Builder, that you can put .swc files in. These SWCs (pronounce 'swicks') contain compiled code already. 3rdparty frameworks (or libraries) are easy to use by downloading their SWCs, and you can also create SWCs with assets from the Flash IDE, for easy access to your asset library. Hence, I guess, the naming of the folder 'libs'. The SWCs in the libs folder are automatically added to the classpath of your project, so you can access the classes therein.
Cheers,
EP.
P.S. Worth noting is that in other development IDE's like FDT or FlashDevelop, SWCs in the 'libs' folder are not neccessarily added to the classpath automatically and might need a little manual configuration.
src should contain your source code. lib contains the librairies that you reference and use in your code (.jar files for example).
EDIT : For Flex projects, you put in lib the .swc files that you load from your source code.
I have a DMD + Tango bundle on linux. Please give me the step by step information, how can I use an external library in D, for example zlib. I have compiled zlib.
I have a file tree like this:
myzlib
├── include
│ ├── zconf.h
│ └── zlib.h
└── lib
└── libz.a
I've got the import tango.io.compress.ZlibStream; call in my myfile.d source.
And these are my questions:
Do I need to copy these files to the dmd/lib directory?
Do I need to modify dmd/bin/dmd.conf file?
How should I call dmd compiler (dmd myfile.d -Llibz.a) or something else (maybe, with absolute paths)?
I've never tried to use external libraries in any other language. Please help me.
The -L flag tells the linker to add a particular directory to its search path.
-l tells it to link in a particular library, and it searches on its search path to find that library.
With DMD, you have to pass flags to the linker with the -L flag.
It can take either absolute or relative paths, but the paths need to be relative to where the compiler is run from. So if you use relative paths, then you always have to run the compiler from the same directory (which generally isn't a problem, since you'd typically have the build command in a Makefile which you always run from the same directory).
The most common thing is to use absolute paths for libraries installed on the system and relative paths for libraries specific to your project.
So, if you have the library myzlib/lib/libz.a, you would pass -L-Lmyzlib/lib -L-lz to dmd.
It would then add myzlib/lib to the linker's search path, and then look for libz.a in its search path (the linker knows to take the part following -l, add lib to the front of it and add .a suffix to the end to get the library that you're looking for).
You can add the linker flags to dmd.conf, but I really wouldn't advise it. The flags in dmd.conf are what dmd always uses for every program. So, you should really only have the flags there that are used in all of your programs.
Rather, feed them to dmd directly (be it on the command line or as part of a Makefile).
As for the header files, you're going to need to duplicate any of their declarations that you need in a .d file.
Header files are used by the C or C++ compiler, not the linker. D shares the same linker as you'd use for C or C++, but its compiler is dmd, not gcc.
So, you need to duplicate the C declarations in a D file. The simplest way to do that is with htod utility, but it only works in Windows or Wine.
Regardless, you'll need to declare the C declarations that you'd be using in a .d file and mark them with extern(C).
If you set up your build to do the compile and link steps separately (like it is common to do with c), it is essentially identical to doing the same with C. First, get your build working without the extra lib (to make sure you are passing all the needed flags to the linker) and then add the libs in as normal. To use a C library from D requires a bindings file, they are effectively just a D file consisting only of prototypes.