Developer forum

Hi Per,

NuGet does not, to my knowledge, support "zip these files, then unpack them when package is installed" features. A NuGet package is, in essense, already a zip-file, so the problem stems from the way these files are unpacked by the underlying NuGet API.

ABCPdf 9.1.1.9 is not referenced anywhere in our codebase, and we've explicitly added checks to make the program fail hard if somebody updates the reference. It must be somewhere on your part - our buildservers will reject any changes to these dependencies, so should not be able to release a package with a dependency to 9.1.1.9. Please correct me if Im wrong! :)

NuGet vs Download zip-file discussion

What is the reason why you use Visual studio to install dynamicweb? You can easily download the zip-file, and then later, update other dependencies if needed.

Visual studio was thought to be for custom development; If you need to build some notificationsubscriber that works with pages, simply reference the Dynamicweb package, and it will find all related dependencies such that everything will "just work" (hopefully!).

If you want to setup install a completely new website, and dont need the references for custom development, using a zip-file is hard to beat: It only does the minimal work needed and never needs to calculate dependencies etc.

The above are two seperate usecases that we both want to support. I would suggest that you use the right tool for your need - both tools are powerful for solving specific goals and none of them can solve each others usecase adequately. What are your thought to this take on things?

BR

Martin

Hi Martin, first thank you for your reply :)

About the reference to ABCpdf 9.1.1.9, I cant really see how it can be in my end ?
I get a repositorie from git with a package file that contains : <package id="ABCpdf" version="9.1.1.5" targetFramework="net46" />

Ones i run "Update-Package -Reinstall" my packages file is edited and <package id="ABCpdf" version="9.1.1.5" targetFramework="net46" /> is replaced with <package id="ABCpdf" version="9.1.1.9" targetFramework="net46" />, that has to be your end that change that ?

The command "Update-Package -Reinstall" should just just reinstall the version I am already using, am I right ?

About Nuget vs Zip.

I get what your saying, and 95% of the solutions we make are custom solutions, and to make a custom solution i have to start somewhere :)

Do you mean to tell me, that I cant expect it to work if I follow your installation guide, and install a new empty DW9?

Would seem very strange to me, that I can only expect it to work in speciel setups?

I have no problems downloading your zip file and installing from that, but I was under the impression that Nuget was the future, and ones it ran smootly, it would be cool to start making our own modules and custom code as Nuget packeges, that we then could just install as needed in our customers solutions.

BR

Per Jensen

Hi Per,

The reason why I think it might be on your end, is that "Update-Package -Reinstall" only reinstalls the current version of each package, but "Update-Package" upgrades the packages to higher versions... See the similarity? If you tell me how to reproduce the described behavior (where "Update-Package -Reinstall" upgrades to newer version), with a step by step guide, please write it here. I've tried it, and cannot reproduce on my machine.

Regarding your question about the future: Yes, you can totally expect that following our guide would work. Doesn't it work, because we have no registered bugs in relation to this?

Use-case 1: Custom development (packages)

Custom code development is definately something that you should do using our packages, and if you use our packages for custom code, things will be "fast", because you should not reference our Admin package. Only the needed dependencies / packages. Have you tried this?

Use-case 2: Setup new version of DW9 (zip)

Download the zip-file. Extract, setup website in iis and follow a wizard. Fast, efficient and works the same way as it's been for quite some time. Also, no extra tools needed (except sql + iis ...)

Use-case 1 and use-case 2 have different needs, and we wont stop supporting one of these delivery methods without giving something that is just as easy to use for our patners. So far we havn't found any way to deliver our software as a "working setup" that beats a zip-file, and I can guarantee you that NuGet will never be able to replace this. Nuget is simply not designed to deliver content, which is why it's so bad at delivering our Admin package (though it does work... eventually!).

Here is a link to the best answer stack-overflow can come up with (which degrades runtime performance - not something we could even seriously consider doing). If you can come up with a really good idea for how to deliver our content in a better way, I would love to hear about it. :)

On the plus-side, we are currently looking at the possibility to precompile all our content, which would significantly reduce our number of content-files AND speed up first-page hit (the speedup is the reason for the investigation).

BR

Martin

Hi Martin

I don't understand why you ask: "What is the reason why you use Visual studio to install dynamicweb". Installing Dynamicweb via Nuget from within Visual Studio is one of two installation methods stated in the manual. We use this method because we don't want eg. frontend coworkers to install DW via a zip-file. We want everyone working on a DW project to be able to pull the project from Git and then be able to run the solution locally (we haven automated creating the IIS website though). So that's why we wan't to install DW via Nuget from within Visual Studio.

Hi Lars,

The reason I ask is, that we envisioned the nuget install to be used for when you want to make a completely custom admin, or when you want to have a headless website (no admin). So I simply ask to understand your usecase, which will make it easier for me to help shape the releases to support how you use our software instead of how we think you will use it. :)

What you describe sounds alot like this: dwinstaller. Is that correct?

BR

Martin

Hi Martin

I would very much like if you would participate in a video meating because it seems like we are talking past eachother. Will you write to me, then we could plan a meeting?

For the record, I had the same exact problem with ABCpdf : I ran "Update-Package -Reinstall", and it changed my version of ABCpdf to 9.1.1.9. This may be some nuget subtility, see for example https://github.com/NuGet/Home/issues/6088

Anyway, to fix this I simply needed to manually update the ABCpdf package back to 9.1.1.5.

Hi Martin,

Any news on this? 

We're are experiencing somewhat the same challenge.

I started a new project and followed the instructions in the manual.

It does work on my machine locally after it fethced Dynamicweb.Admin etc as described in the manual.

However, my inital thought was that /Admin shouldnt be in source control, only the package reference, so when a colleague of mine pulls the project from source control he/she only has to build the project in Visual Studio and the /Admin folder and all its files will be fetched.

However, this is not the case. /Admin is still empty after inital build. I know you write that Nuget isn't meant for serving content which /Admin contains for backoffice etc, however will we be "forced" to add the folder to Source Control? .

If yes, will the package fetch new files, if any, when upgrading in the future. 

Everything works allright, however Dynamicweb.Admin package seems to be the bottleneck atm. And of course, when fetching the package it adds a lot of redundant entries to the web.config file which automatically is being added when creating the empty web application as described.

Hope my post made sense, else feel free to mail me for a call. Would love you spare with you guys regarding what seems to be a common issue.

BR Mikkel

Hi Mikkel,

Regarding NuGet and projects. It is split into 2 parts:

1. Installing the NuGet package

When you add a nuget package reference to a project, the package is installed. This places files etc. from the package into your project and is only ever done once.

2. Ensuring the NuGet dll is available

If you afterwards have a missing package reference (the .dll) you can restore this by building (default settings in VS) or by using the restore nuget package command on your solution.

NuGet does not support your desired setup where it reinstalls itself, if you lack (some of) the files. This part is a bug/feature request that you need to send to the NuGet team - they dont accept new contributors, so I cannot change it even if I wanted to... :/

if you add the files to your solution and then install a new version of Admin, you will be prompted for each file that is about to be overwritten. This can be controlled from the NuGet Manager UI. Ive attached a screenshot of the setting you want to use (here Im showing for installing Dynamicweb.Ecommerce, but it's exactly the same for Admin).

Regarding the web.config: The "redundant changes" are what makes Dynamicweb work. You might not need them, but our software does for various reasons. :)

I have a solution for (almost) getting what you want:

1. Do not check in the /admin folder

2. On your colleagues machine, do a checkout and open Package Manager Console

3. Write "Update-Package -ProjectName [MyProjectName] -Reinstall" <-- This tells nuget that you want to do step 1 again. You can also prepend a configuration for not reinstalling all the other packages, if you want. "[MyProjectName]" should be replaced with the name of your local solutions project-name.

Hope this helps you move forward. :)

BR

Martin

Hi Martin

Thank you for your quick response.

Regarding the first part. We don't encounter any issues when installing the NuGet Package perse, and regarding references, my thought is that you "always" want to reference the package .dll in any case (if needed obviosuly) -  Correct me if I'm wrong.

Regarding the prompt/overwrite all function, it seems like the way to go when upgrading in the future. I guess you're adding more files, if need be, to the /Admin folder on the go. 

I was hoping though, that if my fellow colleague fetched the project from source control and did his/her first time build, it would start fetching files etc for /Admin. This however does not seem to be the case, why, as you mention, you have to do the Update-Package part.

Nevertheless, are you in Dynamicweb, specifying when adding new files to /Admin? - I encountered a rather odd error this morning.

I successfully installed 9.3.10 to my local solution, and everything seemed to work fine. Though I had some 404 errors in the backend. Noticed it while entering my Index (repositories folder) that a filter.js file was missing. I then, just for the fun of if, downloaded the release from the website, and concluded that the filter.js in question was in the .zip version from the website.

Shouldn't the package, Dynamicweb.Admin in this case, contain the exact same files/folders as the .zip file? ..

Futhermore I browsed my current version 9.3.10 via Nuget Package Explorer and again could see the file in fact isn't a part of the package ..

I just wonder, if there are multiple missing files/folders that are missing which could throw even more errors in the backend/backoffice of Dynamicweb as I go ..

I did note that, in 9.4 the exact file I found  that I was missing, has been added.. But still, my logic is that the package should reflect the release 100%, else it will be a bumpy (read buggy) road in the long run. :-)

BR Mikkel

Hi Mikkel,

I agree that it's a big annoying that we can have differences in what we release and what is part of the zip. Unfortunately, the two releases are a bit different. I'll give you an example:

ZIP

web.config contains exactly what we want to make dynamicweb work. Nothing more or less.

NuGet

web.config should NOT override your web.config (you might have added changes to this file). So what we should do instead is do 2 transforms:

1. web.config.install: Adds all dependant assembly bindings.

2. web.config.transform: Adds all other xml from webconfig in a merge-operation

The above step 1 + 2 is NuGet-specific and not something we came up with - it's way more trouble than it's worth, if you ask me. Overriding your webconfig (and therefore your assembly bindings), however, means that our package will break your project*, so that is not a real option.

*If you use any 3rd party package not already part of DW.

Hope this clears up some of the issues - I dont see an easy way to handle the above, unless we switch away from NuGet completely, such that we can maintain these things ourselves (also, nuget does not accept contributors as far as I know, so it's not worth it for us to branch from them).

On my todo list (in a Nice-To-Have priority) I've got a feature whereby we split up our releases even more:

1. Admin is no longer bootstrap

2. We make a number of release-packages: Headless Dynamicweb without Admin, Full Dynamicweb with Admin and Ecom, Full Dynamicweb with Admin without Ecom

3. Each dynamicweb package is release-package independant. Eg. Admin contains no web.config -> Now the above mentioned problem is gone (among others).

It's currently very, very low priority, so this is not going to be available any time soon, unless you start start requesting it. ;)

BR

Martin

Hi Martin,

We still encounter situations when installing Dyamicweb.Admin via the packages that some or more files are missing etc.

Just yesterday, a colleague of mine had some backoffice issues with some .js files located in Admin/Content/JsLib (prototype.js) and in Admin/Resources/js/layout (teaser.js) ..

After he tried to upgrade to latest version (9.4.14), the issue still didn't disappear..

He then downloaded the complete 9.4.14 application from the Downloads section and basically copied the entire JsLib and Resources folder to his project. Then it worked..

I'm very curious on how you push your backend files? - It is obviously not ideal if the package is missing x amount of files compared to the version you're downloading from the Downloads section here on doc..

Due to the fact that we, heavily, are working off of the ability to install/update dynamicweb via packages in order to optimize our work-flow, this is a subject which really needs some attention if you ask me..

Latest Admin nuget (9.4.14) release contains:

Admin/Content/JsLib/prototype-1.7.js & Admin/Resources/js/layout/teaser.js

in the locations you mentioned.

I have no idea why you where not able to unpack the files. Maybe something prevented NuGet from copying the files (check the log)?

You can always open the nuget package with a zipmanager and look for the files that are missing - if you find any discrepency between our zip-release and our NuGet release, please report it as a bug and we will fix it asap. :)

Hi Martin,

It was a vague explanation from me.

My colleague upgraded his 9.4.7 -> 9.4.14 from the Nuget Package Manager which resolved in the before mentioned error. 

I decided to debug a bit further on this and did the following

I downloaded 9.4.14 from the doc site and concluded that the following folders and files were present in the JsLib folder (see attached image) 

I then browsed the same version 9.4.14 from your package feed and concluded that two files are missing (see attached image imageJsLib94).

Just to make sure, we haven't checked all files to compare equality of these or anything like it, so there can me more files which hasn't been pushed/deployed "correctly" to the package in question .. 

Hope it makes sense :)

BR Mikkel