Main Site Documentation

How to package "helper" libraries with your module?


#1

I’m trimming the Midi Module driver to make it more Cerebus-friendly. Plus, it’s just wasteful to use a bunch of code space that will rarely be used.

In any case, I have the module and then two optional DLLs (GeneralMidiUtilities and MidiUtilities). I’d like the DLLs to be installed as part of the module driver package, and to be included by default, or at least placed in the right reference path. The MidiModule driver doesn’t require them, however.

How are folks handling this?

Pete


#2

I should have included this in the first message. Not sure if either of these two GadgeteerHardware entries are appropriate, as the wording doesn’t quite fit.


      <ExtraLibrariesRequired>
        <Assembly MFVersion="4.1" Name="FooHelper"/>
      </ExtraLibrariesRequired>
      
      <LibrariesProvided>
        <Assembly MFVersion="4.1" Name="FooHelper"/>
      </LibrariesProvided>

Also, not sure what to do to tell the wxi to include the DLLs in any case.

Pete


#3

I would also like to know what is the proper way. I have faced this problem with the XBee driver where the implementation is kept in a separate library so pure net mf boards can use it and is referenced by the gadgeteer driver library. In this case the extra library is mandatory.


#4

We’ll soon (<1 week) be releasing a public beta of the next release of GadgeteerCore on http://gadgeteer.codeplex.com/ . The big change is NETMF 4.2 support, but also the GadgeteerHardware.xml and msm.wxs template files have been updated to document this requirement (custom assemblies) better. You’ll have to instantiate a new module template to see this. The readme.txt file in that template also includes detailed updating instructions to help you make your modules compatible with NETMF 4.2 mainboards as well as 4.1.

The specific answer is that you should include the required assembly in (NOT ) in gadgeteerhardware.xml, and the designer will automatically add a reference to it when your module is used. You also need to include the assembly’s files (dll, pdbx, etc) in msm.wxs (the new template provides handy commented-out examples to uncomment :)) I believe this should work with the existing release too.

ExtraLibrariesRequired and LibrariesProvided allow for modules to indicate compatibility with other modules/mainboards enabling design-time error messages. (I’d like to change these names but we would break the schema for existing modules if we did, so we won’t).

@ Pete - we thought about but didn’t fully address the problem of optional extra assemblies. I suspect that if you drag the module in, it will add references but then you can remove them, though I’m not 100% sure that they wouldn’t get re-added by the designer under some circumstance. Something for beta testing if you have a chance :slight_smile:


#5

Thats great news :slight_smile: I thought we were going to have to pack everything in a single assembly :wink: Also, are there any requirements regarding keeping everything in one .cs file? I don’t know why but all drivers I have seen were done this way even though more than one class was implemented. Did i miss something?


#6

No requirement to use a single cs file. The output dll is what is included by the WiX installer, and VS will happily compile many files into that dll.


#7

I was thinking that maybe someone suggested doing it this way. While it’s ok for small drivers, it’s impossible to keep everything in one file or class.