System.Windows.Interactive embedded or dependency?

Nov 7, 2010 at 3:52 AM

I'm building a nupack for Caliburn.Micro and it depends on System.Windows.Interactive, a Blend assembly licensed to be distributed with 3rd party apps.  Should this be embedded with the nupack or should I create a pack for that as well?

Nov 7, 2010 at 6:52 AM

Hmmm, I'm not familiar with the licensing terms of System.Windows.Interactive so I can't really give you advice other than to make sure that you follow its licensing terms. In the meanwhile, I can talk to the owner of that library on our side to ask them to put it in the feed themselves.

Nov 7, 2010 at 7:12 AM

Note that licensing aside, having it in its own package is definitely the preferred approach.  Ideally, we should get the owners of the assembly to own its package, though as Phil said, for now we can just do a quick check with them.

Nov 8, 2010 at 12:51 PM

Let me know what they say and I'll either wait on them (gasp) or put that package in with this pull request as well.

Nov 9, 2010 at 11:13 PM

Ok, I got permission. Could you create this package and submit it?

Nov 10, 2010 at 12:07 AM

No problem.

Nov 10, 2010 at 3:17 AM
Edited Nov 10, 2010 at 3:45 AM

Can you ask them how they would like the assembly versioned?  Caliburn.Micro references


Caliburn.Micro for WP7:

For SL:
For WPF:

File versions all say 2.0.#.0

Nov 10, 2010 at 5:33 AM

Take a look at the fork below to see how I put the Interactivity packages together.  Little nervous about the NET40 and SL40 packages.  Create System.Windows..Interactivity/40/NET|SL40.  NET40 has dll while SL40 has dll  That feels arbitrary, but run it by the blend team and see what they say. WP7 is in System.Windows.Interactivity-WP7.

Nov 10, 2010 at 7:32 AM

It's probably ok as an initial step.  Couple comments:

  • you have a couple .nuspec~ files in there which probably shouldn't be
  • the merge is going the wrong way as it shows the other changes rather than yours. You can just skip the merge, and I'll do it
Nov 10, 2010 at 1:20 PM

thanks.  i think vim is creating the ~ files.  Will get rid of those.

The merge was an accident, I cloned the main repo and have been pushing to my fork.  at one point I pulled from the main repo without thinking.  I can redo the fork if it makes things easier for you, but it shoudln't be a problem during your merge.  just let me know.

Nov 10, 2010 at 8:08 PM

If you don't mind, a clean fork may be best.  Note that you can usually undo the last Hg operation in the Recovery tool, which can often be handy if you make a mistake.

Feb 3, 2011 at 2:04 AM

I can't seem to find this in the package explorer... Has it been added?