I got an issue with the tfs.
Firstly after my tfs server database got full.
So in order to solve it i cleared the table of logs from tfs server.
Now at time of clearing data one of my workspace had checkout of one file. As soon i finished my clearing data, it is giving me this error TF30063: You are not authorized to access Microsoft-IIS/8.5. at every time i try to get latest version.
Thats how i am unable to take latest.
Any help would be appritiable.
Right-click solution
Get Latest Version
Try commit again
Issue started for me when I upgraded to VS2017
For me it helps if i just click the Refresh button at the top of the Team Explorer.
After that, the message disappears and i can normally check in.
For me, it helped just to restart Visual Studio.
Clean the Cache folder on client computer. The folder path is: C:\Users\username\AppData\Local\Microsoft\Team Foundation\5.0\Cache.
Clean the Cache folder on Server machine. The folder path is: C:\Program Files\Microsoft Team Foundation Server 12.0\Application Tier\Web Services_tfs_data
After cleaned, on Server machine, click Start and select Run… to open the dialog box, then input iisreset.exe and click OK, wait it run completely.
I just reconnected to the team project in the Team Explorer and my commit went through, didn't have to restart anything.
I had the same issue. When I closed an open Source Control Explorer window and all the files in Visual Studio, I was able to check in.
I think i got solution, exactly got that how to do.
Do checkout that file and check in an old version of that file
and
than do take latest.
It will not generate this error again.
If you can get a copy of the file that is on TFS you can add it as a new file to TFS, and then do get latest version of the file, and then select keep local when you get the conflict error, and then you can check in the file. After that you can then get latest with no errors.
For me, Run as Administrator from Visual, It will never make this error again.
1 : Open TFS window.
2 : Click on Refresh(F5).
3: Try again to Check-in.
CLick here see Solution (Image):
I have faced same issue while check-in on TFS : You are not authorized to access Microsoft-IIS/10.0.
Using Visual Studio 2017 Enterprise with the latest update installed v15.2 (26430.4) on Windows 10 64-bit. The issue has been happening for awhile, it is not new with the latest VS update. We're using a TFS repository hosted on Visual Studio Online, i.e. our TFS repository is at COMPANY.visualstudio.com.
Frequently, when checking in, or attempting to shelve changes from the Team Explorer window in VS, I'll get an error message indicating I'm not authorized to access Microsoft-IIS/10.0. I've had reports of other developers experiencing this as well.
We've discovered the following workarounds.
Clicking the refresh button on the top of the Team Explorer window and then trying the operation again
If you have multiple workspaces, changing to a different one, then back to the original, then trying the operation again
It appears something is "stale" perhaps with the TFS connection and that refreshing it prevents the error message.
Hitting the refresh button over the Team explorer, resolved the issue.
I had a locked item. When I excluded/undo the locked item it went through.
Refresh TFS not worked for me
In my case the error disappear restarting Visual Studio
or me, it helped just to restart Visual Studio.
Related
I am trying to re-install SSMS after my previous installation went corrupt due to one of my corrupt hard drives (E: in the image below). Trying to uninstall the previous version does not work as it tries to find the uninstaller from that drive.
Running the installer anyways gives me the following error with an un-editable location to point to a valid drive.
"Invalid location. Please enter a valid location to proceed."
I ma pretty sure that the remnants of the older installation must be in the registry somewhere. Any idea where to look for ? Or any alternate solution to solve this problem ?
It seems that you need to remove the following registry key and that gets the new setup going.
For x64 OS :
"HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SQL Server Management Studio"
For x86 OS :
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server Management Studio"
Then try installing after a restart.
I recently had this issue and neither of the above reg keys existed.
To get past this I had to use Shift + Right click and select "Run as a different user". This allowed me to enter the appropriate admin credentials and continue with the install.
I'm trying to publish a DB project in Visual Studio 2013 Professional and the "Publish" button do nothing.
In project properties I checked "Create script (.sql file)". I right click the project name in solution explorer > Publish... > Load Profile (a profile that works for my colleagues) > Publish
Nothing Happens, not an error, warning or anything (same with "Generate Scripts" button).
Visual studio error logs say nothing and I tried to restart the PC, Visual studio and SQL server.
Thank you!
If you have an Azure Cloud Explorer window open in Visual Studio (could be table, blob or queue), that leads to the Publish of an SSDT project hanging.
Close the window and start a new Publish operation. It may take a little longer than usual but eventually that will progress and you'll be able to close Visual Studio as normal.
Thanks to Noel Abrahams for his comment that led to this answer.
EDIT: putting it here as an answer so that it can be more easily found but credit goes to Noel.
Found a fix on the MS Connect site.
In my publish profile I had set the connection string as so:
<TargetConnectionString>Data Source=.\sql2008r2;Integrated Security=SSPI;</TargetConnectionString>
According to the comments on Connect, it doesn't like Integrated Security=SSPI. Instead you should use Integrated Security=True;:
<TargetConnectionString>Data Source=.\sql2008r2;Integrated Security=True;</TargetConnectionString>
Then it all works fine.
I cloned the solution from VCS to a new directory and only this helped.
Other symptoms that I had with this issue:
While editing a table .sql script, Design pane didn't work.
Integrated Security=True; was set in my publishing profile. So Rhumborl's answer is not about my case.
If the solution folder is copied to another machine the issue is reproduced there too.
I tried to Clean Solution before re-cloning, but it didn't work.
For me publishing the database project to a new sql server database with a different name allowed the publish to proceed. Once I'd done that I was then able to publish to the original database again.
I found that having an Azure Queue or Blob Storage opened in Visual Studio Professional 2015 meant that clicking Publish did nothing and I couldn't close the application. After closing those windows which I had launched from the Cloud Explorer, I had to click Publish once again to kick it off. A strange bug.
"Unable to start debugging 'C:\Windows\System32\WWAHost.exe'. The Microsoft Visual Studio Remote Debugging Monitor (MSVSMON.EXE) does not appear to be running on the remote computer. This may be because a firewall is preventing communication to the remote computer. Please see Help for assistance on configuring remote debugging."
Searched for similar posts, but didn't found one. If duplicate just inform.
I am not trying to connect to any remote machine. Just testing on my local machine.
Is there any way to solve this issue. (I'm using Windows 8 Enterprise 64-bit, just a javascript project)
Problem solved. Installed Remote tools update from here and working fine. Thanks for responding. Closing the topic.
I had the same problem. I fixed it by changing properties/compile/target platform to x86 instead of Any CPU. It solved the problem in my case. Hope it helps.
This happened to me just now when I had a website set up in IIS for mydomain.com, and set my project's start up url (Local IIS) to mydomain.com, and then launched the project before remembering to add a record in the host files for the domain:
127.0.0.1 mydomain.com
This got me for a good hour before I remembered I never set the record. Adding the record fixed it right away.
Windows 7 x64, VS 2012
In my case, the Remote Debugging Monitor component was installed and the app was clearly configured to debug locally in settings. This was a WinForms app upgraded from VS 2008, .NET 3.5.
Turns out it was the Windows Firewall. By directly running:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe
A firewall dialog appeared where I could allow msvsmon.exe to run. After a VS 2012 re-start, debugging (locally) was fine!
Ensure you have Local Machine selected in this drop-down menu:
Windows 7 x64, VS 2012, VB.NET
I fixed it like this:-
Create a shortcut on your desktop to "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe".
Right-click shortcut and select "Properties" from the dropdown menu. Select the "Compatibity" tab, tick "Run this program as administrator" and click OK
Create a shortcut on your desktop to "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe".
Right-click shortcut and select "Properties" from the dropdown menu. Select the "Compatibity" tab, tick "Run this program as administrator" and click OK.
To start VS2012:-
Double-click the msvsmon shortcut icon (that you created above, to launch msvsmon). Wait for the "Visual Studio Remote Debugging Monitor (Administrator)" window to display before continuing ...
Double-click the "Visual Studio 2012 Professional" shortcut icon (that you created above, to launch VS2012)
In VS2012, ensure standard toolbar is visible.
In VS2012, ensure "Solution Platforms" dropdown (on standard toolbar) is visible and set to "x86".
and debug now works (for me anyway) ...
However after 15 minutes or so, debug may stop working and you may get the msvsmon error again. If that happens, simply close VS2012 and msvsmon and then start again (from "To start VS2012:-" above) ...
Myself and several other developers have been trying to look for a solution for this problem for about 3/4 hours as Visual Studio crashed then this error would occur (twice in 2 days). I then suddenly (after a lot of debugging and trying other suggestions and headbanging) I somehow realised that the file which was highlighted had changed and when I was trying to debug was not the MVC app project, once I changed it to my project's one it then worked.
Hope this helps and saves people from hours of pain!
I also got this error, I usually run sites under a named user (which is also a database user) and forgot to set the Application Pool. (parliament's answer also helped me)
For me this worked in VS2013:
Save your work, close Visual Studio then reopen your project
I encountered this error as well.
The cause of mine was that I had accidentally emptied out the following property
Properties->Debugging->WorkingDirectory
Changing it to:
inherit from parent or project defaults
Solved the issue.
If you are using Microsoft's Azure, try attaching manually the debugger:
I have outlined the steps in the following answer:
https://stackoverflow.com/a/35738995/1057052
We have just upgraded from TFS 2010 to TFS 2012 and we are getting problems with
tf.exe history *
getting the following error message
"Unable to determine the source control server."
Had the same problem and tried all sorts of values for /collection, finally hit the right one and all TFS2012 tf commands started working again.
In Team Explorer in VS right click the server name and select properties, you need the entire URL parameter including http, the port number, everything.
for me that was
http://devserver:8080/tfs/defaultcollection
so the command is just
tf workspaces /collection:"http://devserver:8080/tfs/defaultcollection"
Alternatively you can configure the connection only once directly in Visual Studio by adding it. After that, tf.exe will automatically use the correct server.
This solution worked for me using visual studio 2017.
I'm getting an error when trying to install sharepoint 2010 on the server (windows server 2008 R2 64bit). The prerequisites installed fine, any ideas what this means?
BEX64 event means a problem with DEP, Data Execution Prevention, or buffer overflow.
It's surely a problem in the downloaded software. You can try to turn off DEP temporary.
I was having the same issue. I tried the install on 5 different servers and got the same result so it wasn't a problem on the server - it seems to be a corrupt download file on the MS Volume Licensing site. When I ran the download using the download manager instead of the web browser download, it kept saying the file was corrupted after the download finished (tried this a few times with the same result). My solution was to download the software from the Trial download site, then use the key I had from the VL download.
The URL for the trial is here
I spent weeks trying to get this to work. And it turned out to be group policy not allowing me to install. So in case that helps anyone else with the same issue.
Attempt the install, then check the windows event viewer and look for any software warnings.
Start -> Search for "Event Viewer" -> Windows Logs -> Application,
Look for an error with a yellow Esclamation mark in a triangle that occored around the same time as the install. And see why it didn't let you install.
Mine said this:
Access to C:\Users\[username]\AppData\Local\Temp\ose00020.exe has been restricted
by your Administrator by location with policy rule {34ae1087-c2cc-409f-a442-e48e70e62efb}
placed on path C:\Users\[username]\AppData\Local\*\*.exe.
I faced the same problem while installing office on my PC.
After all possibility I found that there is existing Microsoft Office folder inside Program files (C:\Program Files (x86)\Microsoft Office) I simply deleted that folder and tried to installed again its work for me.