If I have a package installed, that has built-in documentation, and I want to install an updated version of the same package, is it safe just to erase the old version folder?
Last time I tried, I got some error messages on the documentation, but never understood if the problem came from this fact. Is there an “uninstall package” procedure?
Thank you,
Pedro
If the package has an installer, you should see if it has a corresponding uninstall mode. Otherwise, simple deletion should be safe.
If you do run into any errors, feel free to update your question.
Related
When I save a golang file in visual studio code, it ends up being corrupted -- characters are removed, not in any pattern I have discerned. This has occurred at various times in the past, but has just now recurred. For details, see my bug report, "corrupting file when saving in visual studio code #49465"1.
In the meantime, what I can do until it's fixed? Perhaps I could return to an older version of gopls, but I don't know how to do that.
Any suggestions welcome. I'm stuck until I can successfully save and run my go programs.
Thanks!
Please try running the following command
GO111MODULE=on go get golang.org/x/tools/gopls#master golang.org/x/tools#master
or
GO111MODULE=on go get golang.org/x/tools/gopls#v0.3.2-pre1
In order to make progress on my project, I've downloaded the prior version of go. At least on Windows, the downgrade installs like any upgrade, including offering to remove the existing version.
And I backed up gopls to its previous version using the facilities of VS Code:
ctrl+shift+X to access extensions
right-click on Go
select Install Another Version
wait...wait...wait...
when the list of versions finally appears, select the one you want (I went back a month)
So, the underlying problem still exists, but I'm back in business. I hope these instructions can help someone else battling with the disappearing character bug.
Recently, I have been getting this error a lot and from some research, I got to know that the cause for it is the Xamarin.Build package.
The error text is as follows:
The "User7ZipPath" parameter is not supported by the "XamarinDownloadArchives" task. Verify the parameter exists on the task, and it is a settable public instance property.
I have tried the solution here and here but nothing helped.
My configuration is as follows:
Xamarin version: 4.7.10.38
Visual Studio 2015
The Error occurs when I update the xamarin build NuGet package, If anyone has a solution to this problem please help me.
Thanks.
At last after all this time I was able to solve this problem.
The problem was with Xamarin.Build.Download package.
Now this package had a problem in version 4.7 where it is unable to find the XamarinDownloadArchives task.
I checked a lot of places and for the answer but nothing seemed to help with this issue after that I removed the bin, obj folders for all my projects.
And Updated my Xamarin.Build.Download package to version 0.4.11 and everything started working.
I hope this helps someone else, In case of any queries related to this issue feel free to comment.
Finally! I've come with a solution. The problem was in the Xamarin.Build.Download package, v0.4.0. It was a annidated dependency (in iOS) of Xamarin.Forms.GoogleMaps v2.2.1.
Updating Xamarin.Forms.GoogleMaps to v2.3.0 (the most recent version as of today) solves the issue. Make sure to clean the solution after update NuGet dependencies, though.
I'm kinda new to using composer (but I think it is awesome) so please pardon the noob question.
Folks are requesting exports fancier than csv so I thought I'd install phpOffice excel using composer. But, the master is 'build failing' and the develop is 'build error'. An I correct in assuming the master build failed means I should not install this with composer because it won't work?
In researching this I also found phpOffice spreadsheet, but that appears to be in development still.
Any other alternatives if I cannot use phpOffice excel due to the build status issue?
Regardless of what package you are talking about, if the builds for any of the branches are failing it just means that the builds for any of the branches are failing, that's it.
The master and develop branches may be well ahead of the latest tag, and chances are the maintainers are experimenting with it, and working towards a passing build again.
If you trust the maintainers not to release broken software, then it's safe to use one of the tagged versions, so for example, run
$ composer require phpoffice/phpexcel:^1.8.1
to install the latest stable version.
Note It appears that phpoffice/phpexcel:1.8.1 has been released on 2015-05-01; quite some time has passed since. Whether or not this package works for you, then, is something you have to find out for yourself.
For reference, see:
https://packagist.org/packages/phpoffice/phpexcel
When trying to install glibc-2.15 on Centos-5(Kernel version 2.6.18-238.9.1.el5, gcc-4.6.3), make install step fails with the error message cannot remove/var/db/Makefile'`
The configure command is /data1/downloads/gcc/utils/glibc-2.15/configure --prefix=/data1/downloads/gcc/utils/binutils
glibc-2.16+ solves this problem but I'm restricted by the kernel version. To fix this problem I made changes to glibc-2.15/(config*in|Makeconfig) as mentioned in http://sourceware.org/ml/libc-alpha/2012-06/msg00632.html but this results in configure error(caught signal 2).
Any pointers to help resolve the issue is much appreciated.
Newer Glibc should work with older kernels, shouldn't it? It just disables the optional features. Of course, that probably only goes so far ....
Anyway, the magic build option will be something like this:
/path/to/source/configure --enable-kernel=2.6.18 ...blah..
If the above error is shown during the execution of a VB6 app, is the solution to re-register DLLs that it might be accessing at the time?
Or is this an issue about versions of DLLs not being correct?
Or you might have added an Icon to your application and is not compatible with the OS version just like what happened to me.
Change the icons in your form.
I've seen this error before with controls (ocx). It can usually be solved by recompiling the program with the latest version.
If that's not the issue, I find a good brute-force method to clean the registry and check you have the correct version installed is to simply delete the dll in question (or just rename it) and then use a utility like CClean to delete the orphaned entry. I admit it's a sledgehammer to crack a nut.
You might check the exe/dlls with a tool like Dependency Walker to see if there is a missing component:
http://download.cnet.com/Dependency-Walker/3000-2086_4-10052198.html