I am getting the below error message for a 1st time into my aspnetzero db. I have tried many of the solutions suggested in other areas but none seem to work for my local db
The db owner is sa and i have made the default password set to the infamous '123qwe'; i checked user mapping to make sure that sa owns the db.
i get the below error message when i try to login to the zero system; so the migration works OK also.
{"result":null,"targetUrl":"/Account/ResetPassword?UserId=1&ResetCode=56FB4BDF82&ReturnUrl=%2FApp",
"success":true,"error":null,"unAuthorizedRequest":false,"__abp":true}
well for this issue; the problem was that I wanted 2 pc's, a PC for the road and a desktop for travel, to have a single solution; using GitHub.
in setting up the 2nd pc, I did not follow the exact instructions for creating the project.
Thought I downloaded GitHub repository, something did not work ok in doing the yarn, etc.
To finally fix the problem I re-deleted the solution on the local PC, downloaded the GitHub repository, made sure I did the yarn, vs2k17 build (do not run it) c) npm run create-bundles or npm run full-create.
the below is what helped:
https://support.aspnetzero.com/QA/Questions/6176
I just ran into the same error message.
My issue was caused by Visual Studio running the package restore via npm.
Deleting the node_modules folder and running the restore via yarn in the command line resolved the problem and allowed me to run the copy:node_modules gulp task without errors.
Related
I published my code from local to Terminal Server (Prod). I have everything set on Orchestrator like Robot, Environment, Processes and NuGet package uploaded. I started running the job and it fails after 1 minute of running.
I am getting error saying "Read range error on Orchestrator". I have valid config file on Terminal Server. I even checked Excel activity on Studio it is up to date. Don’t know where the issue is. Could anyone help me here. It would be very helpful in running my bot on Production.
Note: I am using Studio 2018.2.3 and Orchestrator 2018.4.1
On Local machine it is running fine and I am getting this issue only on Orchestrator on Terminal Server
The issue I am facing earlier was related to Dependency files which were missing on Terminal server’s local drive. I copied all dependency files like Excel activities, RestSharp, csvhelper and Newtonsoft.Json from Local machine to Terminal Server under .nuget folder.
Moreover we have to sure we have the same path for %AppData% in both Local and Terminal server.
I currently have a Bamboo task that invokes jspm install from my local app's node_modules installation of jspm but the registry is missing.
The task errors out with "Registry bitbucket not found"
I assume this is because it's installing jspm in the scope of just the task and from that viewpoint the registry is never instantiated.
This is a new issue for me though and just recently started happening after I installed bamboo as a service. Previously, I had set up the registry local to the machine and it seems to have picked it up.
I don't have a working state that I can really revert back to however.
Has anyone else experienced issues with jspm registries in CI server tasks?
Update 1: I stuck a little sanity check in there to execute node -e "console.log(process.env.LOCALAPPDATA || process.env.HOME || process.env.HOMEPATH)" since this is where it looks for the global config anyways and found that the variable that gets used here is not always the same. Sometimes it's my user home (desirable) and other times it's the system's home path (undesirable).
This is the part that's telling of what the issue is:
This is a new issue for me though and just recently started happening
after I installed bamboo as a service. Previously, I had set up the
registry local to the machine and it seems to have picked it up.
Checking what user it was set to use in the services revealed that it was configured to use the local system account which is incorrect. Changing to use the properly configured user account resolves the problem.
Today I upgraded to Visual Studio 2015 Update 2 including TACO Update 8. When I try to build, it fails. In the detailed error log, I see (beside others):
Installing npm 2.14.9. This could take a few minutes... Failed : The
remote server returned an error : (407) Proxy Authentication Required.
I assume this happens since TACO is now detecting the proxy by itself, but for the credentials this is not possible. Therefore I disabled the automatic proxy detection as well as the sandboxed version of NodeJS. Additionally I cleared the Cordova cache.
But the build is still failing. The strange thing is it is still trying to install npm 2.14.9. I get now:
Failed: The specified path, file name, or bot are too long. The fully qualified name must be less than 260 characters, and the directory name must be less than 248 characters,
I assume this happens my %APPDATA% directory is part of a roaming profile placed on a network share. Therefore the content of the APPDATA variable has a length of 82 characters.
Therefore I am using with npm in general the prefix c:\npm, which is working perfect. But unfortunately, TACO ignores it...
So my questions are:
Can I specify the NPM prefix also for TACO?
Can I avoid to install NPM 2.14.9 (which was my expected behaviour after un-checking the 2 options)?
And finally:
It would be great if I could enter also the proxy credentials somewhere.
YES!! I finally found the solution. Turns out the path that was causing the issue was in:
"C:\Users\my_very_very_very_very_long_username\AppData"
So I fixed it by moving my AppData folder according to this article:
http://www.tweaklibrary.com/System/Application-Path/71/Change-default-location-of-the-%E2%80%9CApplication-Data%E2%80%9D-folder/10471/
Rebooted and after that it worked.
Go to the setting window where you clear the Cordova Cache, there is a check box "Use a sandboxed version of NodeJS". Uncheck it and see if you can start to build your code. Also try to add your npm path to system Path environment variables. It's only a workaround.
While trying to deploy an app from Visual Studio, I'm getting an error. I have already set developer mode and also deleted the app package from the packages folder, but it still won't work.
Here's the error message:
Error : DEP0700 : Registration of the app failed. Deployment Register
operation with target volume C: on Package
App_1.0.0.2_x64__m0fsgersa29a0 from: (AppxManifest.xml) failed with
error 0x80070002. See http://go.microsoft.com/fwlink/?LinkId=235160
for help diagnosing app deployment issues. (0x80073cf9)
Do I need to set anything else?
I got this when attempting to debug a project from a shared folder.
Opening the project from a local folder first resolved the issue.
I know there is already an accepted answer, but I had a totally different problem with the same excact error message. When th app was running I took a look in the SQLite database with a program that I didn't close when I uninstalled the app and re-run it from Visual Studio. I think that Visual Studio couldn't overwrite the database as I was 'using' it.
Closed the program and voila the app run smoothly.
Hope this helpes anybody else as I was stuck for precious hours!
In Windows 10 there are two possible cause of this problem are as follows,
Previously installed app is locked and preventing VS to delete while deploying the application. Goto C:\Users\{you user}\AppData\Local\Packages and delete the folder of your application. Now rebuild and deploy your application.(this was the solution in Windows 8 devices as well)
If it is still not working, double check if you have removed the below entry from appxmanifest file. If you are targeting Desktop Name="Windows.Desktop" entry should be there in the file. If it is Phone, Name="Windows.Mobile" should be there in the TargetDeviceFamily. You can have both in the configuration but sometimes Microsoft will suggest to keep separate configuration when you submit the application for STARTS testing.
< Dependencies>
< TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.0.0" MaxVersionTested="10.0.0.0" />
< /Dependencies>
Hope this help in figuring out the reason and solution for "Error : DEP0700 : Registration of the app failed" error.
Don’t worry, the solution is actually very simple.
Error: DEP0700: Registration of the app failed. An internal error occurred.
So you’ve started your Windows 8 app development journey. All things are going smooth until one day you hit this error when trying to run/debug your app. The error says “Error: DEP0700: Registration of the app failed. An internal error occurred with error 0x80073D05. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues. (0x80073cf6)”
This is a very cryptic error and does not give you any info about what the problem actually is. The problem is that Visual Studio is not able to delete the application data in your local packages folder.
Don’t worry, the solution is actually very simple. On your Windows 8 machine, go to C:\Users\\AppData\Local\Packages\ folder. There you will find a folder that has your application’s Package Family Name in it – you just need to delete that folder. The issue is that while your app is in development, it might have a random GUID as its Package Family Name, so the folder will also have that random GUID as its name which makes it hard to know which folder belongs to your app. Again, that is easy to find as well. Right click your project in Visual Studio and click properties. The value you see in the “Package Family Name” field is the name you should look for in the folder. Simply delete it and build your solution again and it will run like a charm.
Read more details at http://paraswadehra.blogspot.com/2012/12/error-dep0700-registration-of-app.html
For me this was caused by being signed in with my Microsoft account in windows instead of the local user account. Logging in as a local user fixed this.
DEP0700: Registration of the app failed
For me the error DEP0700: Registration of the app failed, was raised because my Store App was installed from the actual Microsoft Store. I had to uninstall it and then I could debug my app smoothly.
I got this when I tried to run the project from a ReFS filesystem. Running from NTFS worked. My error code was 0x80073cfd.
I stumbled over the same issue today and after a few hours I found out, that the problem was because I moved the AppIcon files into a subfolder and forgot to adjust the references inside my package.appxmanifest. Unfortunatly the corresponding error message didn't point into this direction and all the above mentioned solutions didn't help for me, so hopefully this helps someone else!
In my case, I was opening one of the App files (Log Files). When deploying, Visual Studio attempts to remove all the files and packages (if uninstall is on in the properties). It was unable to remove the Log file as it was opened. When I closed all files, and tried again, it worked.
I ran into this error when testing some code in domain-bound and non-domain-bound scenarios (which requires me to have a domain account and a non-domain account on the same machine).
I found that I had to uninstall the application from the account I originally deployed it from before I could deploy it again on the other account.
My problem is that there is another Microsoft account in my computer that installed the app from Microsoft Store.
Nothing from the provided solution helped.
The only thing that solved my problem is to delete that account that I installed the app there.
SQLlite database might be opened. Just close the sqllite and try to deploy again.
I am just learning how to setup my continuous integration bots in xcode 5 and having a really bad time. First, I was having problems with code signing identities, but after reading this great blog post, that problem disappeared.
Post:
http://matt.vlasach.com/xcode-bots-hosted-git-repositories-and-automated-testflight-builds/#comment-21
Now, after fixing those errors, other errors appeared. Every time I integrate, I get a warning like this:
The file "Pods.xcconfig" couldn't be opened because there is no such file.
And I also get an error, saying a header for a pod is not found. I assume this error is a consequence of the previous warning.
Everything works perfect locally, running on devices, archiving, the problem only happens when i try to integrate with the bots.
Should I add something to the PodFile? or is it something on the osx server itself?
I really need help before I go crazy about this!!
Thank you.
Better solution is to add a new scheme, which is used only via server (duplicate your normal scheme). Then select option manage schemes, expand 'build' and add new Pre-action with following code:
cd ${SRCROOT}
echo "Installing Pods"
pod install
You can update and many other things over here. The only problem is that the build where it updates has old content, you have to once again tap integrate. Remember to keep this scheme shared.
--edit--
You ofc have to commit this and run bot on this scheme (you can change it in your server -> safari local xcode bot url -> settings -> scheme.
You are receiving this error because your mac server doesn't have the pods created in the directory that the Xcode bot is checking them out into. This is as expected because it would be odd to check-in the results of the pod install into your source control system. I wasn't able to find a way for the BOT to run the pod install/update commands so I came up with the following workaround:
Ensure your bot is configured to NOT clean before each integration
Run your bot then search through the resulting logs for the path that files are being checked out to.
Search for "IDEDerivedDataPathOverride" That path will end in /DerivedData, if you look in the parent folder of that you will see a "source" folder. This is where your bot will continue to checkout updates for your project
Note: The source directory is owned by your server user, you will need to access it as that user. Use the su command to do so
Install cocoapods on your mac server if you haven't already
On the mac server, in the source directory found above, navigate to where your Podfile is located
Run pod install and ensure all your specified pods are installed
Double check the file permissions of the newly created pod directories and ensure they are owned by the same user as the other files. Use chown to fix if necessary
Fire off the Bot and watch it complete successfully!
The only issue with this solution is that if a clean is ever performed you will need to run pod install again. This was good enough for tonight, I'll have to look for a way to script the pod install later utilizing the Pre-actions in the Build section of the Scheme used in the bot definition.