Hello every time I type any dotnet command it will configure dotnet again.
I don't want to be like this, I don't want that every time I type command dotnet is configuring again. Help me turn this off.
configure again
The error message "Failed to create prime the NuGet cache. new failed with: -2147352571" hints at a known problem when you install the 2.0 CLI next to the 1.0 one and then return to run anythin in 1.0 afterwards.
Latest information on this topic is from June this year when the 2.0.0 tools were still in preview phase. The info back then was to wait until 2.0.0 is released and then there might be another update to the 1.0 series to fix problems if both are installed together.
In the meantime, you can work around this by either uninstalling the 2.0 series dotnet cli or by making sure this environment variable is set before running the 1.0 cli again:
DOTNET_SKIP_FIRST_TIME_EXPERIENCE=1
This is the original problem report with the same error message you didn't mention: https://github.com/dotnet/cli/issues/6381
Here's the discussion for the temporary fix: https://github.com/dotnet/cli/issues/6550#issuecomment-301261209
And here you find the latest information about no updates for the 1.0 series until 2.0 is final (2.0 is final in the meantime, but apparently 1.0 hasn't received any updates since): https://github.com/dotnet/cli/pull/6633#issuecomment-311882413
Related
When I do symfony self-update I get the following error - how can I solve it?
Backup failed, rename D:\SERVER\Symfony\symfony.exe C:\Users\FairyWilbury\.symfo
ny\autoupdate\2019-07-19_14-57-14-79024bb-old: The system cannot move the file t
o a different disk drive.. Canceling upgrade.
UPD.
I have just realized that the latest symfony version seems to be 4.3 with 4.4 due to release in November https://symfony.com/roadmap/4.4
Yet whenever I run symfony new --full %projectName% it suggests I should update to 4.6 (and then fails to update as described above). Screenshot of the command line: What can this problem be?
First of all, you're mixing up Symfony Local Web Server and the Symfony PHP framework. You can use the web server, which is a single executable command line developer tool, to start a new Symfony-based project or start a local server that makes your web application available for testing and debugging while you develop it. The framework, on the other hand, is the code base you build web application on.
When you run
symfony self-update
from the command line, you (try to) update the web server, not the framework.
The latest version of the web server, at the time of writing, is 4.12.10, while the framework is at 5.0.5 (or 4.4.5), so, as you can see, they're completely independent from each other.
Back to the original problem, and I was struggling with this as well, the catch is that we both use Windows and installed the web server (symfony.exe) to a folder in drive D: (in your case it's D:\SERVER\Symfony). While it's running, it stores config and other files in a ".symfony" directory in the folder of your Windows user account (C:\Users\FairyWilbury). And during the self-update process, that's where it tries to move the original symfony.exe file. For some unknown reason, it cannot do that between different drives, not even in an Administrator-privileged command line window.
Strange, as it is, the only solution I found was the following.
I created a TEMP folder on drive C:
Copied symfony.exe from its folder on drive D: to C:\TEMP
Opened up command line, and switched the current dir to C:\TEMP
Ran symfony self-update -- this time it went smoothly
Closed the command line window
Moved the new symfony.exe file from C:\TEMP to the folder on drive D:
Removed C:\TEMP folder
I know it's a bit cumbersome, but we have to consider that Windows is not the most popular development platform for PHP applications. ;)
okay, look, in this case, I dont really find anything about this symfony self-update stuff, so...
In the version title the third part (so the 1 in 4.6.1) is a patch, what that only contains bug fixes, so you need the latest minor version first 4.6.0.
Basicly you need follow this doc:
symfony/doc/upgrade_patch.html
And, as it starts above, first you need follow this doc (attentively):
symfony/doc/4.2/upgrade_minor.html
This upgrade_minor.html writes: The composer.json file is configured to allow Symfony packages to be upgraded to patch versions., so ...
This command helped me to update symfony binary:
sudo symfony self-update
I've been using 1.1 on Win 10. When 1.2 came out, I tried upgrading but it actually falled back to 0.3. According to sashko a reinstall was necessary, which solved the problem for some. However, nothing happened when I uninstalled and rerun the installer. No files were actually modified. Deleting the %localappdata%/.meteor folder didn't help either. As the installer would no longer put anything there.
The farthest I could get is to get a dev build with a git clone, but I'd like to use a release version either 1.1 or 1.2. Otherwise I'm not able to update my project with a checkout meteor build.
Wrote a bunch of comments on other threads but none of the suggestions helped thus far, so I thought this deserves a new separate thread.
The solution was to clean the registry of meteor entries.
Credit goes to avalanche1 at: https://forums.meteor.com/t/windows-install-uninstall-hell/2375/7
Just integrated Flyway into our app and it works great in the following situations:
brand new app install with empty schema, creates the schema_version table and executes the complete schema script after which app is on it's way..works great!
have a patch sql script, we set the version higher than the current version, patch get's applied automatically, version is incremented, no issues here!
Now the problem is the following:
We have older versions of our app out there. Say our current application version is 7.5 (schema version 1.0), when a user is using 7.4 of the application (we will manually set the schema version to say 0.9) and is upgraded to 7.5 the schema upgrade to v 1.0 should be migrated using an Upgrade script rather than the complete script for an empty database. Make sense? How can I approach this scenario, it does not seem to be covered by Flyway.
In summary we have these two scenarios:
Brand new install of our app v7.5:
- installation of new schema v1.0 uses MX_1_0__complete.sql
Upgrade of app from v7.4 to v7.5:
- upgrade of schema from v0.9 to v1.0 should use MX_1_0__74upgrade.sql
since both target schema versions are 1.0 how does Flyway choose one over the other? In addition either only an upgrade or a complete script is to be executed depending on the existing version#, not both!! If current version is 0.9 then upgrade script to be chosen, if current version is 1.0 then nothing is to be done, if there is no current version then the complete 1.0 script to be applied to create a new schema.
Should be simple enough...
Always run all scripts.
Brand new install of v7.4: Run 0.9 script.
Brand new install of v7.5: Run 0.9 script and 1.0 upgrade.
Upgrade v7.4 to v7.5 ... : Run 1.0 upgrade.
Has anyone else had trouble with the new release of Cloudera manager? '4.7' With brand clean ubuntu vm nodes it seems to be placing a file in /etc/apt/sources.list.d called cloudera-manager.list with "http://archive.cloudera.com/cm4/ubuntu/precise/amd64/cm/ precise-cm4.7.0-SNAPSHOT contrib pointed" to as the source, however this url does not exist and when ever it tries to install my nodes if fails.
Does anyone know where this url is kept on the manager so I could change it before it sends it to my nodes?
Greg,
The repository URL is constructed based on the version of the CM server that you are running. So if the server is reporting itself as "4.7.0-SNAPSHOT", then that's what the node installer will use. Now, we've not published any release that describes itself as 4.7.0-SNAPSHOT, so I'm left scratching my head as to how you got into this situation. If you still have that installation, I would recommend that you:
1) Check the reported version of the server from the Support menu at the top right.
2) Check the full package version(s) as reported by "dpkg -l | grep cloudera"
so that we can establish where the build came from.
Thanks.
PS: The installer url you reference in your update is the latest installer and not a 4.6 installer. It's the one people should use for sure.
i followed these instructions for building an adhoc version in xcode 4.0 (4.3 compilier)
i used the distribution profile instead of dev
added entitlements.plist
same project worked for adhoc before i upgraded to 4.3
http://diaryofacodemonkey.ruprect.com/2011/03/18/ad-hoc-app-distribution-with-xcode-4/
now:
project compiles finde (via archive) i can share it.
i can push the file into itunes
BUT
i cant get the app on my device. i always get an error "invalid rights"
Maybe someone can help me on this.
Try using the same profile for Debug and Build and Run (as debug, not release) with the target set to your Device.