none
Common framework library for VSIX extrensions: question about versioning...

    问题

  • Hey experts,

    I'm currently working on about 3 VSIX extensions for LightSwitch at once: EME, a new Skinning extension, and "Extension 3"... 

    These three have some classes in common, so it would seem logical to put them inside a common library.  

    What happens if a developer has EME 1.11 installed, which uses v1 of the framework, and then installs the Skinning v3, using another version of the framework?  Are their any guidelines or ideas on what the best practices would be when it comes to versioning?  

     

    Kind regards

     

    Jan


    Lightswitch blog: http://janvanderhaegen.wordpress.com || About me: http://about.me/jan.van.der.haegen || "The improbable we do, the impossible just takes a little longer." (Steven Parker)
    2012年1月6日 15:12

答案

全部回复

  • If the common pieces are in one Library I would think that it's version would be it's own.


    Derek
    2012年1月6日 17:46
  • Hey Derek,

    thank for your reply, you're absolutely right.  However there's one use case that worries me...

     

    Suppose:

    Extension1 (X1, version 1) uses the framework (F, version 1).

    Extension 2 (X2, version 1) uses the same version of the framework (F, version 1).

     

    A couple of months later, I publish an update of the framework and both extensions:

    (X1, version 2) -> (F, version 2)

    (X2, version 2) -> (F, version 2)

     

    Then what happens if the users updates extension1, but not extension2...  So the user has the following installed for a LightSwitch application:

    (X1, version 2) -> (F, version 2)

    (X2, version 1) -> (F, version 1)

     

    There would be a serious incompatiblity at runtime... Is there any way to prevent this, preferably at compile time (like with nuget packages: set a minimum and maximum version of dependent packages), or even at runtime?

     

    Kind regards

     

    Jan


    Lightswitch blog: http://janvanderhaegen.wordpress.com || About me: http://about.me/jan.van.der.haegen || "The improbable we do, the impossible just takes a little longer." (Steven Parker)
    2012年1月7日 11:06
  • Is it worth the hassle?

    I know it bothers you as a programmer to have 'duplicate code' but I am sure you don't want your end-users to run into any problems :)


    Make Them Ask: That's a LightSwitch App?

    http://LightSwitchHelpWebsite.com

    2012年1月7日 15:09
  • Hey Michael,

    although you are right, it will prevent the different extensions from working together...

    You know me, I'm a dreamer :-) Should probably think this through a bit more first...


    Lightswitch blog: http://janvanderhaegen.wordpress.com || About me: http://about.me/jan.van.der.haegen || "The improbable we do, the impossible just takes a little longer." (Steven Parker)
    2012年1月7日 17:49
  • The big question is:  What happens with deployment?

    We need to keep our apps as small as possible - and have them do as much as possible . . . until we can dynamically send XAML, ViewModel objects, and method code for Screens to an intelligent (universal) HTML5/JS LS client, we have to tediously figure out a modular approach to LS development.

    We want to use LS for web site functionality with integrated business forms - and vice versa.   These are Internet business requirements.  It is no longer acceptable (or necessary) to have to use 2 separate technologies: LS should do it all. Merge WebMatrix (or whatever the current flavor is for ASP.NET web pages) with LS.  LS is a wrapper technology with a flexible shell.  A databased menu system will manage Screens.  Metadata, database information, and all information available from the web are going to be used by our biz apps.

    Today, there isn't much of a problem with modular LS Desktop (IIS) apps.  Users setup the icons and the load time is always good.  When updates are available, they take a few minutes to download them.

    However, (today) we must build separate small LS apps for the browser for open sites and/or needed customer/prospect/partner business functions.  This is a problem.

    To be clear:  This scalability problem is with Silverlight - which LS inherited.  We can't develop large apps with SL that load fast.  Dynamically loading down an entire XAP file to run one Screen will soon choke both the server and the client - not to mention what it does to the network.  The user response needs to be fast.  A user WILL quickly go across mutlple XAP modules with a single task:  GL, IV, AP, AR, OE, PO, HR, PR, etc. - and the kicker is that they will will also need to reach across to many partner systems.  This is the real world.

    Hopefully MS has already engineered LS v2 and next gen XAML to dynamically instantiate Screen objects on the server and download appropriate client ViewModel and View XAML objects to an HTML5/JS intelligent client (based on the client device form factor).

    We should have been doing this from the beginning with Silverlight. 

    As biz app developers, we must have a technology that can reach all devices. 

    It isn't MS' fault that Apple and Google won't run Silverlight or any technology designed by MS - no matter how good the MS technolog is.

    Soooo . . . MS simply said:  OK, we'll go with the least-common-denominator:  HTML5/JS.  Thank goodness that HTML5/JS has enough power to function as a minimal intelligent client for our biz apps. 

    It certainly doesn't seem like a difficult task with everything we have available from MS, to instantiate server and client code for a Screen - and to support HTML5/JS pages in LS Screens.   This is simple and will massively scale.

    LS Extensions should just be part of building an LS app.  We should be able to use Extensions for app code as well as tools.  There should be no difference between building part of an LS app or building a tool to build LS apps:  It is all just XAML and programming code.  XAML and programming code are simply application data.  Visual Studio is a business application that works with data.  There is no difference between a General Ledger application and Visual Studio.  It is just that Visual Studio is an application that still uses flat files (like IBM punch cards) instead of a database like a General Ledger system.

    Yes, I will design and write a General Ledger system (or any biz module) that takes full advantage of available metadata.  A system that will dynamically create programming code that works hand and hand with state machine code, workflow, databased biz rules, OData, etc. to do what is needed for business and governmental functions.

    It is not a question of IF, but rather a question of WHEN we will get there.

    I am very careful about what Extensions we use with LS v1.  We need to eliminate LS technology ambiguity with documentation.

    I greatly appreciate all of your efforts.


    Garth Henderson - Vanguard Business Technology
    2012年1月7日 18:24
  • One of my favorite stories/jokes is about a little boy who goes to his father & asks him a question. The father suggest that the boy go ask his mother. The little boy looks at his dad & says, "But Daaaaddd, I didn't want to know THAT much about it". LOL.

    I have no idea why that popped into my head.. :P


    Yann - LightSwitch Central - Click here for FREE Themes, Controls, Types and Commands
     
    If you find a reply helpful, please click "Vote as Helpful", if a reply answers your question, please click "Mark as Answer"
     
    By doing this you'll help people find answers faster.
    2012年1月16日 4:10
  • Hey experts.

    Unfortunately, I had to unmark the answer that was accepted by moderators.  The question still remains.  I can make multiple VSIX extensions work together because they reference a common library.  The library ships with each of the extensions.  However, since the end-user can have different versions of each VSIX installed, there might be incompatibilities at runtime.

    At best, I can export some kind of [RequiredFrameworkVersion] from each VSIX, and have the framework check if all exported versions throughout the application match, and at least show a proper warning to the end-user instead of waiting for runtime incompatibilities...

    Isn't there a standard / guidance on how to resolve this kind of versioning incompatibility at design time?

    Cheers

    Jan


    It's your story - time to switch on the innovation. || About me || LightSwitch blog

    2012年4月3日 7:40
  • Took me a while, but the answer is actually extremely simple...

    The VXISmanifest has built-in support for this scenario.  Simply deploy the common library (EME) as one VSIX, add it as a reference in the VSIXmanifest of another (more like: "required reference"... more like "dependency" actually)...


    It's your story - time to switch on the innovation. || About me || LightSwitch blog

    2012年4月12日 23:59