locked
Sharing javascript libraries between different Lightswitch HTML Client solutions. RRS feed

  • Question

  • If you have a javascript library that you maintain and would like to share it between all your Lightswitch HTML solutions you can add the file as a link like you would normally do. Publishing your solutions works grear; however, you would notice that it is not being copied to your solutions bin\debug folder when debugging. In thus to add the file as a link seems fairly useless.

    The solution is to add the following code to your HTMLClients project file right before the end of the </project> tag in your HTML clients project file (the one ending in .jsproj). Make sure to edit out the comment's that surrounds the BeforeBuild and AfterBuild tasks so they get executed. This way the file will be present in the correct folder during debugging and you can debug as you would normally.

      <!-- To modify your build process, add your task inside one of the targets below and uncomment it. Other similar extension points exist, see Microsoft.Common.targets. -->
      <Target Name="BeforeBuild">
      </Target>
      <Target Name="AfterBuild">
        <Copy SourceFiles="%(Content.Identity)" DestinationFiles="$..\..\..\bin\$(Configuration)\HTMLClient\%(Content.Link)" SkipUnchangedFiles="false" OverwriteReadOnlyFiles="true" Condition="'%(Content.Link)' != ''" />
      </Target>

    It does not seem to matter if you add it to BeforeBuild or AfterBuild.

    What would be great is ff anyone knows how to accomplish this without cracking open the project file! Please let me know if this is possible.


    Regards, Christopher Maduro


    Tuesday, September 23, 2014 7:08 PM

Answers

  • Hi Chris,

    The approach we've taken is to roll our JavaScript library into a local NuGet package.  This allows us to easily introduce the NuGet package into new projects and provides all of the in-built NuGet versioning.

    The process of creating a local NuGet package is surprisingly simple and allows you to automate the introduction of the associated script entries into the project's default.htm file.

    Please let me know if you'd like to try this approach and need some pointers.

    • Proposed as answer by ADefwebserver Sunday, September 28, 2014 6:41 PM
    • Marked as answer by Angie Xu Friday, October 3, 2014 2:31 AM
    Sunday, September 28, 2014 4:35 PM

All replies

  • Hi Chiris,

    Generally I follow this way to share code between Client and Server, add a code file to both the client and server so that it is shared, first add it to the client project and then link it into the server project.

    We can link existing files by right-clicking the project, hover over Add, select Existing Item..., select the file in the dialog, click the drop down arrow next to the Add button, and select Add As Link.

    According to your description above, it seems that you use Copy Task, since I don't have much experience with it, you could take a look at the article in msdn library.

    Please let me know if there is anything that I can do to help.

    Best regards

    Angie


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Sunday, September 28, 2014 8:07 AM
  • Well, thanks for the info but that is not actually what I was doing in this case. In this case I had a javascript library I wanted to share between all my Lightswitch HTML projects. Instead of having 10 copies of my library and maintaining the code in 10 different places, I maintained 1 copy and linked it to all my projects using this method. 

    What I was wondering is if this is the current best practice for this scenario. In fact I can't think of any other options.


    Regards, Christopher Maduro

    Sunday, September 28, 2014 3:48 PM
  • Hi Chris,

    The approach we've taken is to roll our JavaScript library into a local NuGet package.  This allows us to easily introduce the NuGet package into new projects and provides all of the in-built NuGet versioning.

    The process of creating a local NuGet package is surprisingly simple and allows you to automate the introduction of the associated script entries into the project's default.htm file.

    Please let me know if you'd like to try this approach and need some pointers.

    • Proposed as answer by ADefwebserver Sunday, September 28, 2014 6:41 PM
    • Marked as answer by Angie Xu Friday, October 3, 2014 2:31 AM
    Sunday, September 28, 2014 4:35 PM
  • The library is actively being developed, so it's important that all projects have the latest version. How easy is it to update with a local nuget package?

    Regards, Christopher Maduro

    Sunday, September 28, 2014 7:50 PM
  • I'm very interested in this topic as well. During the Sept 2013 Town Hall meeting this was in fact one of the questions/suggestions that I put forward to the LS team.

    The way that I have approached this in the past was to create a special "local content delivery project" (empty web project) that contained all the CSS and Javascript files where they would be maintained and to then include that project in all other LS related Solutions and to link to those assets from the LS default.html file via a http//localhost:xxxx/... URIs. This worked OK for development but became awkward during deployment as you have to have a separate version of the LS default.html file for deployment. So not ideal either.

    The build process you mention above sounds interesting and I might give that a go next time. I've not created a Nuget package before so not sure what is involved... but we also need to be able to update those assets constantly during development, so having to create a new Nuget package each time may not work for us.


    Regards, Xander. My Blog

    Sunday, September 28, 2014 11:01 PM