The JumooTranslate.Core NuGet package has a dependency on Microsoft.AspNet.SignalR.JS >= 2.2.1 and therefore brings in scripts outside the App_Plugins folder for JQuery and SignalR (in the /Scripts folder).
Besides adding the (unused) jQuery script or conflicting with references for the website itself, the package.manifest references version 2.2.1 ("~/scripts/jquery.signalR-2.2.1.js") and the dependency could be updated to a higher version (e.g. 2.2.2).
You could fix this by pinning the NuGet dependency to a specific version (not recommended) or including the SignalR script in your own package (within the App_Plugins folder).
Umbraco actually has the nuget package for SignalR.Core at v2.2.1 so the JS version has to match that (it doesn't include the JS file which I suspect is because umbracoDeploy does?)
I thought quite long and hard about putting it inside the App_Plugins folder but i was concerned about clashes you might get if another package or app put the SignalR.JS package into your solution, loading multiple versions of the js file could cause issues.
While it is in the default location - the backoffice's client dependency loading will prevent multiple loads of the script even if it is referenced in multiple packages.
You are right really the script needs to be dynamically located by a controller and I did look at getting a controller return the script location (and i may well update it to do this) so the version can be updated, but again while it should be fine for minor versions (like 2.2.1 to 2.2.2) i am not sure what that will do to umbraco if you change the core version of SignalR too.
I suppose i need to do some experimenting to confirm that moving the scripts won't break other things, i was trying to keep everything using standard nuget packages, longer term that makes everything much easier to keep-up-to-date but you are right its not ideal.
I understand your point of view regarding clashes with other versions, but that could already be the case if other packages reference a different version (by also bringing in the JS using NuGet). Multiple loads could also be a problem if other packages won't use the same NuGet location, but include it in their own App_Plugins folder...
In summary: there is no silver bullet to ensure the correct script/version is loaded (once). However, the current setup DOES break if the depencencies are updated (by just doing a PM> Update-Package).
Thanks Kevin! I could also uninstall the jQuery NuGet package (that was a dependency of Microsoft.AspNet.SignalR.JS), so the Scripts folder is empty again...
Maybe Umbraco could publish some guidelines for this in their documentation? It would be great if we could use ES2015/ES6 modules, so every package can import their required libraries/versions without conflicts...
Remove Microsoft.AspNet.SignalR.JS NuGet references
The
JumooTranslate.CoreNuGet package has a dependency onMicrosoft.AspNet.SignalR.JS>= 2.2.1 and therefore brings in scripts outside theApp_Pluginsfolder for JQuery and SignalR (in the /Scripts folder).Besides adding the (unused) jQuery script or conflicting with references for the website itself, the
package.manifestreferences version 2.2.1 ("~/scripts/jquery.signalR-2.2.1.js") and the dependency could be updated to a higher version (e.g. 2.2.2).You could fix this by pinning the NuGet dependency to a specific version (not recommended) or including the SignalR script in your own package (within the
App_Pluginsfolder).Hi,
yes i know - it's a bit of a pain really.
Umbraco actually has the nuget package for SignalR.Core at v2.2.1 so the JS version has to match that (it doesn't include the JS file which I suspect is because umbracoDeploy does?)
I thought quite long and hard about putting it inside the App_Plugins folder but i was concerned about clashes you might get if another package or app put the SignalR.JS package into your solution, loading multiple versions of the js file could cause issues.
While it is in the default location - the backoffice's client dependency loading will prevent multiple loads of the script even if it is referenced in multiple packages.
You are right really the script needs to be dynamically located by a controller and I did look at getting a controller return the script location (and i may well update it to do this) so the version can be updated, but again while it should be fine for minor versions (like 2.2.1 to 2.2.2) i am not sure what that will do to umbraco if you change the core version of SignalR too.
I suppose i need to do some experimenting to confirm that moving the scripts won't break other things, i was trying to keep everything using standard nuget packages, longer term that makes everything much easier to keep-up-to-date but you are right its not ideal.
I'm only talking about the
Microsoft.AspNet.SignalR.JSreference, as the core library can be updated without issues:The
Microsoft.AspNet.SignalR.Corepackage is indeed referenced byUmbracoCms.Core, but can be updated to 2.2.2 without issues:I understand your point of view regarding clashes with other versions, but that could already be the case if other packages reference a different version (by also bringing in the JS using NuGet). Multiple loads could also be a problem if other packages won't use the same NuGet location, but include it in their own
App_Pluginsfolder...In summary: there is no silver bullet to ensure the correct script/version is loaded (once). However, the current setup DOES break if the depencencies are updated (by just doing a
PM> Update-Package).Hi
I've done a beta version of the next release of JumooTranslate.Core with the signalR script moved to within the app_plugins folders and SignalR dependency removed. : https://www.nuget.org/packages/JumooTranslate.Core/1.1.4-beta
should get you a version without the signalR 'noise'.
Thanks Kevin! I could also uninstall the
jQueryNuGet package (that was a dependency ofMicrosoft.AspNet.SignalR.JS), so the Scripts folder is empty again...Maybe Umbraco could publish some guidelines for this in their documentation? It would be great if we could use ES2015/ES6 modules, so every package can import their required libraries/versions without conflicts...
is working on a reply...