I have created a new DotNetCore 2.0 web project in VisualStudio 2017.
I have docker running in machine with Docker Server Host configured for Windows.
While running solution i'm getting below error,
'The DOCKER_REGISTRY variable is not set. Defaulting to a blank
string.'
Building myfirstdotnetcore Service 'myfirstdotnetcore' failed to
build:
Get https://registry-1.docker.io/v2/: net/http: request canceled while
waiting for connection (Client.Timeout exceeded while awaiting
headers).
I had this issue and has resolved after taken below steps.
Run Visual Studio as Administrator
Your running Docker host should logged-in to your DockerHub account.
This is very important
The main reason for this issue is Visual Studio couldn't download nano server image from docker hub. So always make sure that you logged in to your dockerhub account from running host
I needed to set docker registry Environment Variable. Path needs to be lowercase for some reason.
[Environment]::SetEnvironmentVariable("DOCKER_REGISTRY", "d:\docker\registry\", "Machine")
I found these related issues on github:
https://github.com/Microsoft/DockerTools/issues/130 (this is tracking the fix)
https://github.com/aspnet/Docs/issues/7234
TLDR; This error is misleading, and can mask several internal docker errors which Visual Studio currently swallows (these should be visible in your build output) - this is expected to be fixed in Visual Studio 2017 15.8 but as of 15.8.2 this is still a problem and the bug is still open, so I assume its still on the way.
Until then, the general consensus seems to be that the following step combination should workaround most of the underlying issues. NB! these might need to be repeated after machine restarts.
Run Visual Studio as Administrator
Ensure you are logged in to Docker - e.g. run docker login
Restart Docker for windows (right click in system tray and select restart)
I'm not certain if the order of the above might be important.
In Docker Settings -> Network, I switched the DNS Server setting to "Fixed" as below and it worked for me! Hope that helps
I tried everything mentioned above but nothing worked. The issue for me was simply the fact that I did not have an environment variable named DOCKER_REGISTRY, as it clearly states in the error, so I created a system environment variable named DOCKER_REGISTRY and gave the path C: to it. This answer helped me. Remember to restart your system after creating the variable.
Do you have the detailed error message?
I had a similar problem, turned out that virtualization wasn't enabled on my machine.
run 'systeminfo' in power shell, and make sure that hyper-v is enabled
I did almost like #David Silwal said.
I ran Visual Studio as Admin.
I was already logged-in on my docker hub account, but even like that, it wasn't working.
So I logged-out and logged-in again. Then, it worked!
Just clean the project solution explorer and rebuild the solution.
Run Visual Studio as Administrator
Right click on Docker tray icon -> Restart
Related
I'm new to Visual Studio, and I just downloaded the Xamarin package over the weekend. The very first time I ran the Android Emulator, it seemed to work fine. (This was simply running the "Hello World" base-script. Then when I opened the emulator again, it began having Deployment errors.
Deploy Failed
Pressing Yes, yields no results. After some research of my own, I believe that the issue may be because Hyper-V is not running. Enabling it should be simple, but i have tried a few different methods and cannot seem to get it to run. One way I tried was via Powershell: Powershell Feature Name Unknown
Having tried that, I tried to enable it manually via settings: Settings
To my understanding, there should be a few different folders here called "Hyper-V" or something to that effect on top of Hypervision Platform folder. Is this why my emulator isn't running, because I don't have access to the Hyper-V folders, or could something be wrong in Vis Studio itself? Like I said, I'm very new to this software and workflow so any trouble shooting ideas would be appreciated.
I'm trying to get running a docker support with Visual studio 2017 for a .net core 2.0 web app running on linux containers. I'm working on machine with win 7 OS, so I must use a Docker toolbox with Virtual box. I've already checked this question: How to get docker toolbox to work with .net core 2.0 project, but I got stuck in the following problem, when trying to run it with VS:
Volume sharing is not enabled. Enable volume sharing in the docker ce
for windows settings
So far I know that there is a default volume mounted under the C:\Users, so my project files should be copied somewhere under this folder in case I don't want to mount any other volume. So I copied them there.
When I check the settings of my Virtual box, folder seems to be shared:
I can even cd into this folder with command line, but still can't get over this problem. Any ideas about this?
Finally I got this running. Error message comming from VS is very misleading and it has nothing to do with volume sharing. Eventually I realized that problem is in running a debugger, because when I ran solution with Ctrl + F5 everything was ok and container started correctly. Problem occurred only when running with F5 and trying to attach a debugger.
Then I found some clues in console output. VS tries to download some tooling for debugging containers with powershell script named GetVsDbg.ps1. When running this script I could observe errors like:
Add-Type : Cannot add type. The assembly
'System.IO.Compression.FileSystem' could not be found.
Finally I fixed this issue by updating powershell version which was somehow in collision with my .net framework installed on my machine.
Well in my case it turned out that I had changed my windows password and docker wasn't able to get access.
So it was just
uncheck shared drives
Apply
Check again. Enter new password
restart docker
Below setting helped me getting rid of this error. Check the drive you want to share and click apply. This might ask you your network credential just enter in case it pops up.
Docker settings
Thanks,
Rakesh
I fixed it by running following command in Powershell:
docker network create nat
I got same issue attempting to publish an Azure Function App to a Container Registry.
Newer version of Docker Desktop for Windows 2.3, has new interface. I had to got to Resources|File Sharing and add a new Folder. This resolved that issue...
My email address has changed and now I can't log into Visual Studio 2017.
The error is "We could not refresh the credentials for the account. Failed to refresh the access token".
How can I fix this?
This bug will be fixed in a future version.
For now:
Close down VS2017
Go to "C:\Users\{username}\AppData\Local\.IdentityService"
Rename "IdentityServiceAdalCache.cache" as shown below. (for example just add an underscore to it)
Restart VS2017 and log in.
NOTE: There are similar issues that this won't resolve, but this worked for me.
Open Visual Studio. Click Help, Send Feedback, Report a Problem...
This brings you to a login screen. If you log in from there, it will log you into Visual Studio.
What worked for me was to rename .identityservice and then restart VS and log in to your VSTS account. It then recreates a new .identityservice that it can access.
I tried by deleting only the IdentityServiceAdalCache.cache as in the accepted answer but it did not fix the problem.
For the record, I managed to fix it by deleting every files within the .IdentityService folder (located in C:\Users{username}\AppData\Local.IdentityService).
I have read dozens of posts on this topic discussing clearing out .IdentityService. I tried every variation of this solution that one might think of. None worked.
I ended up poking around and trying to manually login to my Microsoft account using Internet Explorer, but I could not connect to https://login.microsoftonline.com. I added the https://login.microsoftonline.com address to my Trusted Sites in Internet Options. Once I had done this, Visual Studio was able to connect to Microsoft and validate my account.
When an error occurs, Visual studio will log it's error messages in the following folder. Please check the logs located at
%Temp%\servicehub\logs
This can also be caused by network restrictions. Please disable your virus guard or firewall and check.
This issue can also be caused by running VS "As Administrator" and the administrator is a different user. Just some FYI.
None of these answers will resolve that issue unfortunately.
Very old thread but if someone is still having this issue, then try following in my footsteps:
I just deleted the entire .IdentityService folder, and launched visual studio again... It asks you to log in and works normally. (for me)
Make sure you can access https://login.microsoftonline.com
If your network is blocking that (perhaps to block Microsoft webmail), then the above solutions will not pertain to you. Either unrestrict access, or you will need some off-line version.
In case someone is still looking for an answer. What worked for me was checking that the AppData folder and Local folder were not on 'read only mode' in the path "C:\Users{username}\AppData\Local.IdentityService" and it just worked!
Check to make sure that your PC no limit(IP-Firewall) to Internet connection access.
Disable or turn off VPN
It happened to me when using an account that uses my organization's email-domain, and I guess it tried to verify it and it couldn't find it in their database, and as soon as I used an account with a onmicrosoft.com domain, it worked.
The interesting part is that it allowed me to create the Microsoft account with this organization email and I still use it for DevOps, and it just stopped me when signing in with Visual Studio, I don't understand why this difference is.
I hope this can help someone..
I have VS 2017 and had this exact issue. Simply deleting
C:\Users\{username}\AppData\Local.IdentityService did not work for me.
Follow the steps 1-2 below to see if you might have and identical cause of the problem, and the rest how to solved it if so.
Go to C:\Users\{user}\AppData\Local\Temp\servicehub\logs and open the latest error logs from VS.
IF you see "Retrieved tenant memberships, found '2' owned tenants", then follow the rest of the steps.
Go to azure portal then login under the username you are
trying to use.
The following steps may change by the time you read this, but you
want to get to step 6. Go to Manage Azure Directory.
Click "Switch Tenants"
I was linked to 2 tenants, one of which I did not need. This is what had been causing my issues. Select the useless tenants, and click "leave tenant".
Once this is completed, close all instances of VS.
Delete C:\Users\{username}\AppData\Local.IdentityService.
Open VS and login to your account.
I found the same behavior when using Administrator user.
Any other user can login and activate the license only for himself.
I don't think there is a way to activate for Administrator, which makes using this licensing awkward for usage in a shared resource (i.e. build server).
The one solution which worked for me was resetting the domain password and restarting the system.
I just wanted to share this because i was struggling with the same problem since 8 days tried everything on net and this worked.
Hope it helps someone :)
I updated Visual Studio with latest package and after rebooting my PC issue was solved. I was able to log-in
Opening VS as admin worked for me, none of the above did
I was getting this error from our proxy having restrictive rules in place, I was able to add the sites to a whitelist that were being blocked while trying to login.
Some of the sites I whitelisted in Webmarshal were:
*.windows.net
*.msocsp.com
*.ws.symantec.com
*.digicert.com
*.clicktale.net
app.vssps.visualstudio.com
demdex.net
For me it was due wrong system time, after setting correct time it got fixed automatically
I had the problem of not being able to sign in to VS after not using unity for a long time and then updating everything. The way I solved it was to open VS and then click help. This opened the sign in box with 'Personalization Account'. I clicked 'Account options' under the afore mentioned heading, and changed the 'Embedded web browser' to 'System web browser' in the right window. This enabled me to log in via my Edge browser and everything worked fine.
I just fixed it by changing folder to be public.
folder files: "C:\Users{username}\AppData\Local.IdentityService"
right click and choose property and uncheck the hidden and apply it.
If you are under a domain network there is a workaround (quick fix),
Adding or changing the following key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb
ProtectionPolicy = 1 (DWORD)
Check the most recent modified files at %temp%\servicehub\logs.
Check StorageUtilitiesSingleton-10788-lqnuymos-1.log
For an error like this: The computer must be trusted for delegation and the current user account must be configured to allow delegation.
If that is the case this might help you.
I has this issue recently.
Tried all the options above, none worked.
Get it sorted, after repairing Visual Studio, doing all the updates, restart and updated again, restart, another repair and bang! Worked like a charm.
Instead of doing all this, change embedded broswer to system browser so it will works normally in default browser and gets updated in VS.
In VS 2019 enabling System Web Browser instead of Embedded web browser fixed it for me,
Hope this helps someone
https://learn.microsoft.com/en-us/visualstudio/ide/work-with-multi-factor-authentication?view=vs-2019
I tried multiple things above such as
Renaming c:\users[user]\appdata\local.IdentityService
Logging directly in https://login.microsoftonline.com (noticed certificate issues)
Adding https://login.microsoftonline.com to the Trust Sites list in Internet Options
Opening VS as non-admin as well as admin
Reviewed the logs here: %Temp%\servicehub\logs
I also installed Chrome, setting it to the default browser, because many features were saying IE is no longer supported
Reviewing the logs gave me the clue I needed to solve my particular issue. The log stated there was an issue with SSL trust.
Consequently, I ran our local version of rootsupd.exe and installed any related Microsoft root certificates such as the DigiCert Global Root G2 to the Trusted Root Authorities. After rebooting my machine, I noticed VS began recognizing my account and was actually already signed in.
Exact error:
Severity Code Description Project File Line Suppression State
Error DEP0001 : Unexpected Error: -1988945906 TestApp
What does it mean? It seems it isn't problem with application, it works OK on PC.
Version of OS: 1511, Windows 10 for phones 10.0.10586.164
I've experienced the same problem after updating Visual Studio community to Update 2. Typing in CMD (under admin rights) the following command solved my issue:
net start IpOverUsbSvc
Thanks to Agrgg for a good tip ;)
This kind of error happens very randomly and usually it means there was an issue during the deployment of the app. Things to check:
Developer mode is correctly enabled on phone
Uninstall the app from phone, rebuild solution and then try debug again
Check that the architecture for all projects is set accordingly (ARM for debugging on real device)
Sometimes the VS debugger hangs up, so closing VS and kill from Task Manager all VS processes that are eventually running and restart VS may also help.
I had the same error with deploying onto Windows Phone 8.1 device. In my case the problem was in Windows Phone IP over USB Transport (IpOverUsbSvc) service, which wasn't running. The deployment error disappeared after I'd started the service manually.
I had the same problem.
"net start IpOverUsbSvc" didn't worked for me (throws Access is denied Exception).
I have followed following steps to fix.
Start Run (Windows+R), Type: services.msc
Start/Restart Windows phone IP over USB Transport.
For the RPi, I have RPi3 with WIOT (build 14376) this error happens after failed deployment. Just restart VS and it'll deploy ok.
After trying some of the answers already provided and nothing worked, I fixed the error by simply restarting the phone.
After that the error was gone for me.
I had the same issue, and found that in my case it was occurring while the phone was downloading system updates in the background.
App updates/installations from the app Store were also prevented from downloading/installing.
After the update had finished, all was back to working again.
As Windows Phone 10 doesn't seem to make it obvious that it's downloading updates, maybe worth checking this out if you hit this problem.
I had the same error, solution is here: https://msdn.microsoft.com/ru-ru/library/windows/apps/jj863509(v=vs.105).aspx
Look at Checking BIOS settings required by Hyper-V for Data Execution Prevention. You must select "Turn on DEP for all programs and services except those i select" and in my case application deploys successfully.
For me, it was as simple as unlocking the phone so that the computer would have access to it.
I had this issue as well. None of the answers helped me. IpOverUsbSvc was up and runing, phone reset, system reboot, nothing...
The issue was fixed after a Visual Studio "repair": control panel -> Programs and features -> select VS2015 -> Repair
I got a similar error.
The reason the error occurred for me was because I forgot to add the new splash images in assets after deleting the old ones.
The solution was to add the images. To get the correct image names and sizes, I used this extension for visual studio.
For Windows 10 (desktop) users
I faced this problem after I uninstalled Windows 10 SDK. It deleted the IpOverUsbSvc service from the system.
Solution
Download the Windows 10 SDK .iso installer
Inside it there is Installers folder.
Find Windows IP Over USB-x86_en-us.msi. Install it. (Don't worry if there is no setup window, it installs fast and silently).
I didn't even have to reboot VS2015, it just worked.
Check if the IpOverUsbSvc service is running
Open a Powershell prompt and type Get-Service -Name *USB*
Or go to the Services window. There you should see the IpOverUsbSvc running.
So, I think I get the trick. After plugged in your Windows Mobile device, Windows App Deploy can see W10M device, but once your device goes to lock screen, WPD can not detect it anymore.
You should to plug out and plugin again, with screen unlocked, to make it detectable. (I'm not a really English speaker).
This is the error that is thrown by our automated build suite on Windows 2008, while running ICEs (after migrating from WiX 2.0 to WiX 3.0):
LGHT0217: Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.". in light.exe(0, 0)
The FAQ is now deleted, however, the text from it said:
In WiX v3, Light automatically runs validation-- Windows Installer Internal Consistency Evaluators (ICEs) --after every successful build. Validation is a great way to catch common authoring errors that can lead to service problems, which is why it’s now run by default. Unfortunately, there’s a common issue that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to fail. For details on the cause and how to fix it, see Heath Stewart's Blog and Aaron Stebner's WebLog.
Additionally, these are the errors that show up in the event log:
MSIInstaller: Failed to connect to server. Error: 0x80070005
Product: [ProductName] -- Error 1719. The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.
Intuitively:
VBScript and JScript were registered under admin.
Integration service has permissions for the desktop interaction and all the files
Builds succeed, when executed manually on the same machine by another user or even user logged in as integration account (via RDP)
I'm out of ideas so far.
How do I solve this problem while keeping ICE validation?
End of the story:
After fiddling with the permissions of the integration account, DCOM, service activation, etc. without any luck, I finally simply disabled ICE validation in the continuous integration build, while still keeping it in the local build.
To disable ICE validation you can set SuppressValidation to true in the .wixproj file:
<PropertyGroup>
<SuppressValidation>true</SuppressValidation>
</PropertyGroup>
Or pass the -sval command line option to light.exe.
Adding the TFS build controller account to local admin group and restarting the windows service did the job for me.
I found the root cause. I tried everything I found, including custom validator extension similar to one posted in Re: [WiX-users] light.exe failed randomly when running ICEs..
It's not a concurrency issue as suggested in various threads. It's caused by a too large Process Environment Block (PEB).
It turns out Windows Installer can’t handle a process environment block larger than 32 kB. In my environment, due to number of variables set by the build system and their size (for example, PATH variable containing multiple duplicated values), PEB was about 34 kB.
Interestingly, per Environment Variables, Windows XP and 2003 had a hard limit of PEB set to 32 kilobytes. That would probably cause an easy-to-catch build break in an earlier phase of the build. Newer Windows' doesn’t have such limit, but I guess that Windows Installer developers limited their internal environment buffers to 32 kB and fail gracefully when the value is exceeded.
The problem can be easily reproduced:
Create a .bat file which sets environment variables which size exceeds 32 kB. For example, it can be 32 lines of set Variable<number>=<text longer than 1024 characters>
Launch cmd.exe
Execute the batch file you created
From the same cmd.exe window:
Try building the MSI package using WiX with ICE validation on OR
Run smoke.exe to validate your package OR
Simply run msiexec /i Package.msi
All the above commands will end up reporting Error 1719 - Windows Installer could not be accessed.
So, the solution is - review your build scripts and reduce number and size of environment variables so they all fit into 32 kB. You can easily verify the results by running:
set > environment.txt
The goal is to get file environment.txt smaller than ~30 kB.
The correct description (without a solution, except if adding the CruiseControl account into local administrators group can pass as a solution) of the problem:
Quote from Wix 3.5 & Cruise Control gives errorLGHT0217:
ICE validation needs an interactive account or administrator privileges to be
happy. See for example WiX Projects vs. TFS 2010 Team Build (2009-11-14) or Re: [WiX-users] Help with building patch (2009-11-20).
imagi is totally right! I could not believe this is the true answer. Supressing validation and making TFS user Administrator are not good solutions. Plus I could not find NT\Authority to add it to Administrators group and was totally stuck in this.
I got the same error on Windows Server 2012 Datacenter as Build Agent.
To solve the problem :
List item
Go to Environment Variables on the build agent machine
Create two System Variables
"PF86" which is equal to "C:\Program Files (x86)"
"PF" which is equal to "C:\Program Files"
They are so short because I want to save characters.I made them without the final backslash because TEMP, TMP and others were made so and I decided to stick to MS standard for these variables.
Edit PATH variable by substituting every "C:\Program Files (x86)" with %PF86% and every "C:\Program Files" with %PF%
Close and build and enjoy!
It worked for me. :)
UPDATE
I found a better solution : Rapid Environment Editor will do all this and even more for you. Automatically.
I faced the same problem and did not like to suppress ICE validation. My setup: I used my own computer as a build agent on Visual Studio Online (VSO). My solution was to change the account used to run the service on my machine. Instead of using Network Service or Local Service I simply made the service log on with my own account which had all the necessary rights.
From http://wix.sourceforge.net/faq.html#Error217:
In WiX v3, Light automatically runs validation--
Windows Installer Internal Consistency Evaluators (ICEs)
--after every successful build. Validation is a
great way to catch common authoring errors that can lead to service problems,
which is why it’s now run by default. Unfortunately, there’s a common issue
that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to
fail. For details on the cause and how to fix it, see
Heath Stewart's Blog
and
Aaron Stebner's WebLog.
I was getting same ICE error, but the problem turned to be corrupted Windows Installer Service.
This solution worked for me:
http://support.microsoft.com/kb/315353
Log on to your computer as an administrator.
Click Start, and then click Run.
In the Open box, type cmd, and then click OK.
At the command prompt, type msiexec.exe /unregister, and then press ENTER.
Type msiexec /regserver, and then press ENTER.
Restart Windows
Also, verify that the SYSTEM account has full control access permissions to the
HKEY_CLASSES_ROOT hive in the Windows registry. In some cases, you may also have to add Administrator accounts.
I have some suggestions.
Try updating the Microsoft Installer version on the build server
Make sure you use the newest release of WiX 3.0, since it's 3.0 release stable now.
If all else fails, try running the build service under a specific build user who you can fiddle with permissions for...
I got this error from my Azure build agent running on-premises.
My solution was to upgrade its user account from "Network Service" to "Local system account".
Go to your build machine and restart the Windows Installer service
None of the above suggestions worked for me, for me the anti-virus (mcafee) came into the picture and looks like it updated the vbscript.dll registry entry to a wrong DLL location. These are the things to keep in mind:
Some of the WiX ICE validations are implemented using VBSCRIPT.
So while compiling the MSI, the build server would need access to the c:\windows\system32\vbscript.dll.
Chances are that somehow the user that runs your build lost access to this DLL.
As mentioned in the above answers do look for the admin access/registry access and make sure your user has it.
Here are the steps that I took to fix the issue:
Open cmd (run as admin) on the build agent machine.
Run RegEdit
Select the root, then click ctrl + f and Search for the following registry entry : {B54F3741-5B07-11cf-A4B0-00AA004A55E8}
Look for the InprocServer32\Default Key
On my build agent, the path was replaced with a mcafee DLL location. I updated the path back to c:\windows\system32\vbscript.dll
Editing the registry entry was not easy, as it was a protected registry entry. I used the below link to get access permissions changed before I could edit the property: Edit protected registry entry
Once I updated the path, everything started working as usual.
My solution is similar to Vladimir's one. My CI user was admin of the computer.
But the following steps were mandatory to allow my jenkins build to succeed:
log in as CI user using rdp
open a dos command prompt
execute: %windir%\system32\msiexec.exe /unregister
execute: %windir%\system32\msiexec.exe /regserver
then i got a successfull job