With newer versions of DNN, they excluded the Bulk Install files used to bulk install modules.
We used to copy the following files in the install folder on newer versions to make it work.
When I navigate the following URL, I get an Exception: dnndev.me/install/install.aspx?mode=installresources
Exception:
It looks like a missing definition in a DLL.
How can I fix this?
Upgrade.Upgrade.CheckUpgrade() is no longer exist on latest version of DNN.
Check the history related to it
Don't just paste your old code, there's a couple update at DNN Install.aspx.cs file.
You'll need to make adjustment to it.
Related
Is it possible to use Cake to always get the latest version of a specific NuGet package? I know NuGet itself only allows you to set that at the base Nuget.config level. There are some internal packages that we would like to always get the latest version of (some of our database entities), while other internal packages we don't want to force a latest (our extensions package, for example). Right now we have to go through and manually update projects that rely on those packages, and I would like to automate those "always get latest" at build.
I don't see anything using any of the NuGet add-ins, but I am new to Cake so I'm hoping I am just missing something.
Has anyone had any luck using Cake to always retrieve the latest version on the feed for specific named packages, and just use the current packages.config version for the rest?
The short answer is that you can do anything that you want.
Cake out of the box will attempt to adopt established best principles for reproducible builds.
With the preprocessor directive, you could simply omit the version information, and Cake/NuGet will fetch the latest version. However, once downloaded to the tools folder, Cake/NuGet will not fetch it again. What you could do is add a custom step in your bootstrapper to clear the tools folder each time before build, and then the latest version will be downloaded each time.
Note: This is NOT a recommended approach, but rather something custom for your setup.
I am trying to set up a stack project that uses the postgresql-simple package among others. When trying to stack build, all of the dependencies for postgresql-simple installed without issue, but stack is having trouble installing postgresql-simple itself. I get the following error:
C:project> stack build --extra-include-dirs="C:\PostgreSQL\8.4\include" --extra-lib-dirs="C:\PostgreSQL\8.4\lib"
... omitted ...
*****************
--extra-include-dirs=C:\PostgreSQL\8.4\include
*****************
--extra-include-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw32\include
--extra-include-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include
*****************
--extra-lib-dirs=C:\PostgreSQL\8.4\lib
*****************************
--extra-lib-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw32\lib
--extra-lib-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib
Process exited with code: ExitFailure 1
Logs have been written to: C:\Users\User\Desktop\draftkings\NFAccuracy\.stack-work\logs\postgresql-libpq-0.9.1.1.log
Configuring postgresql-libpq-0.9.1.1...
Setup.hs: Missing dependency on a foreign library:
* Missing C library: pq
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
I've tried also specifying the paths in my stack.yaml file, same error.
I've tried manually copying the library and include files from my postgres installation to the mentioned ...\mingw64\lib and ...\mingw64\include folders. Same error.
I have the files libpq.dll and libpq.lib in my C:\PostgreSQL\8.4\lib folder.
I feel like I'm missing something obvious but I can't get this to work and I'm not sure what I'm doing wrong. Any help is appreciated.
Update
I forgot to mention two important details.
First, I have added C:\PostgreSQL\8.4\bin to my PATH. As far as I know, this works as expected, because I got past an error about pg_config missing, to the error I currently have.
Second, I also tried adding the lib and include directories to my PATH, but this did not change the error.
I should also mention my Postgres installation works fine on its own.
I know that the Snowdrift project uses PostgreSQL and builds with Stack on Windows. They have a build guide on their site. It looks like one difference is that they mention:
Add the PostgreSQL bin directory to the path C:\Program Files (x86)\PostgreSQL\9.4\bin
Can you try adding that to the PATH and see if that fixes it?
There was some kind of version mismatch.
Installing Postgres 9.4 instead of 8.4 allowed the postgresql-simple package to be built in the manner I was attempting.
My stack project, without intervention by me, defaulted to using resolver: 'lts-3.7' This provided version 0.4.10.0 of the postgresql-simple package to my project. I wish I had a more detailed answer, but all I can tell is that this version of postgresql-simple (which is fairly recent) works fine with PostgreSQL 9.4 (which is also recent).
And thankfully, using haskell and postgresql-simple built against Postgres 9.4 libraries is having no issue communicating with my 'remote' (virtualbox) database which is Postgres 8.4.
I'm tempted to flag my question as not constructive unless others find this useful info.
I'm unfortunately not very experienced in CentOS administration, and was hoping someone might be able to help me understand and get past a small hurdle. I was hoping to run yum update on the system, but ran into some Transaction Check Errors:
file /etc/php.ini from install of php55-common-5.5.11-1.el6.x86_64 conflicts with file from package php-common-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/curl.so from install of php55-common-5.5.11-1.el6.x86_64 conflicts with file from package php-common-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/fileinfo.so from install of php55-common-5.5.11-1.el6.x86_64 conflicts with file from package php-common-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/phar.so from install of php55-common-5.5.11-1.el6.x86_64 conflicts with file from package php-common-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/pdo.so from install of php55-pdo-5.5.11-1.el6.x86_64 conflicts with file from package php-pdo-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/pdo_sqlite.so from install of php55-pdo-5.5.11-1.el6.x86_64 conflicts with file from package php-pdo-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/sqlite3.so from install of php55-pdo-5.5.11-1.el6.x86_64 conflicts with file from package php-pdo-5.3.3-40.el6_6.x86_64
It sort of looks like it's saying that some newer version files are conflicting with older version files. Is there a standard way to fix this? I was mainly just trying to update so that I could install Java later, but wasn't expecting to run into these errors. If it helps, the server is mainly being used for hosting a few websites with apache and mysql. Thanks so much for any help, it's greatly appreciated.
Edit: To add some more clarification, I had previously edited the baseurl variable in the /etc/yum.repos.d/centalt.repo file, which was originally set to
baseurl=centos.alt.ru/repository/centos/6/$basearch
The reason I changed the location was because I was previously getting an error when trying to run yum update, mentioned in this other stackoverflow question https://unix.stackexchange.com/questions/132674/repository-metadata-repomd-xml-for-repository-mratwork-centalt which had an answer recommending replacing the URL with
baseurl=mirror.sysadminguide.net/centalt/repository/centos/6/$basearch
Is there a different url I should be using instead?
You have a non-official repository which provides the php55-* packages which conflict with the official php-* packages.
You currently have the php-* versions installed.
If you want to switch you can try manually installing the matching php55-* package for every php-* package you have installed in one yum command (though that may not work).
If it doesn't, you might need to remove all the php packages you have installed first and then install the php55 versions after that.
VS 2013 fails to restore a package - the package contents are not materialized - although VS/nuget appears to think that it did restore the package successfully.
If I manually uninstall and re-install the same version of that package, it works as it should.
A bare-bones repro can be downloaded as a zip. This repro has a
single solution with a
single project with a
single file, "packages.config", specifying a
single package, "breeze.edmbuilder -version 1.0.4", containing a single file, edmbuilder.cs
single folder, "App_Start", contains nothing but
the .csproj says it should have "edmbuilder.cs" which is ok because
it WILL have "edmbuilder.cs" when the package is restored.
When I build, VS reports that "edmbuilder.cs" is missing ... and indeed it is missing.
However, the package was downloaded; I know this because the build produces a "packages" folder that contains "Breeze.EdmBuilder.1.0.4" wherein I see that "edmbuilder.cs" is present and in the right place.
When I issue the command install-package breeze.edmbuilder -version 1.0.4, nuget reports
'Breeze.EdmBuilder 1.0.4' already installed. NugetRestoreFail already has a reference to 'Breeze.EdmBuilder 1.0.4'.
There is nothing wrong with this package AFAIK. For when I uninstall-package breeze.edmbuilder and then reinstall with install-package breeze.edmbuilder -version 1.0.4, the install works and the missing edmbuilder.cs appears in the "App_Start" folder where it belongs.
The failure is repeatable in place.
close the solution
delete edmbuilder.cs from "App_Start"
delete the "packages" folder
optionally delete the .suo and bin and obj directories
re-open the solution and re-build
You'll get the same failing behavior ... and the same ability to manually uninstall and reinstall.
FWIW, removing the reference to edmbuilder.cs from the .csproj has no effect.
No matter what I do, I have to manually uninstall and re-install the package.
WTF!
p.s.: I am using VS 2013 Update 2 RC. I doubt that the "RC" matters as this problem came to my attention from a customer. You never know.
p.p.s: This is not about the build failing and I don't care that this solution would never run. What you see here is a stripped down version of a real app that would have worked. The only question is "why no restored file?"
Package Restore is NOT the same as installing a package. What you are seeing is by design. It simply downloads any missing packages in the packages folder. No more. No less.
Package Restore was added so you wouldn't need to commit the packages folder to source control.
It is expected that you would install a package then commit the changes made to your project files as well as any files that may have been added like your edmbuilder.cs, essentially anything inside your project folder. You would exclude the packages folder.
Now when you get the source from source control everything would be present except for the package files. Package Restore would download those and now your working copy is complete.
See NuGet's Restore Package insists on specific package versions
Is this stupid or what?
Thanks to #Kiliman for explaining that my horrible experience is "by design".
So how do you actually get the content you thought was being restored? Do you install each package one at a time. That's insane.
I was going to observe that there is no nuget equivalent of an npm install that would fetch all the packages you need ... when I discovered that there actually IS an almost-equivalent. It's just not obvious and I wonder how many people know it exists.
It's a two step process:
FIRST restore the missing packages ... THEN
Issue the command: Update-Package -Reinstall
This re-installs all packages in every project in your solution.
If you only want to re-install for a specific project, try:
Update-Package -ProjectName 'YourProjectName' -Reinstall
In both procedures, the -Reinstall switch strives to install the exact versions of the packages spelled out in your package.config ... and not newer "updated" packages which may or may not work for your project (but see the documentation for exceptions).
Read about update-package -reinstall in the official nuget documentation entitled, "Reinstalling Packages and its Pitfalls".
Do not miss the cautionary remarks. Clearly this technique is but an approximation of what you'd expect from other package managers.
Good luck, peoples.
I have an install.ps1 script in my NuGet package. This script runs both during a new install (after all the files have been copied) and during an upgrade.
I want to show a Getting Started page during a new install, but for an upgrade I want to show the Release Notes.
I found this great answer that tells how to open a URL and it works great. But I am stumped on trying to tell the difference between a new install and an upgrade.
The best solution I have come up with so far is to add a Release Notes link to the top of the Getting Started page, but that is something that could easily be missed by upgraders, and is an unwanted distraction for new installers.
I don't think it's possible to know if the current operation is install or upgrade. When NuGet upgrades a package, what NuGet does is basically uninstall the existing package and install the new package.
I suppose you could do something with install.ps1 that "dirties" the project in some way on the first install, which you will not clean up with uninstall.ps1. Maybe insert a dummy file into the project (outside of the normal NuGet handling, so the file won't get uninstalled automatically) or add some other dummy element to the project file. Then, when you see those "leftovers" from a previous install (which were purposely not cleanly uninstalled), you will know that you are installing an upgrade.