When i run "Run Personal Build" from the TeamCity addin to visual studio 2005 it appears to connect correctly as i can use the my changes to show my additions. However, in the Personal build window, the right window (i'm guessing that this is where you'd select a build configuration is blank) And as such, i cannot select a build configuration to light up the RUN buttion.
I've verified that the path to svn.exe is correct (detected) and i'm using my explicit login creds.
I've also been flipping through the manual but am not finding the appropriate information easily. (although i'm fairly certain i'm just looking for it wrong)
Anyone else have this problem? what else should i be looking for?
As a note, this machine had a copy of VisualSVN installed which has since expired.
Thanks
after some more troubleshooting and it appears that no one else has this problem, increasing my permissions on the teamcity server seemed to correct my problem.
Related
My installation of Visual Studio was fine previously, but has started acting weird lately. Some of the symptoms include
Visual Studio randomly hangs or crashes
Visual Studio won't start
Intellisense disappears sometimes
Plugins are not working, or are failing to start
I can't install or uninstall tools
I can't connect to source control anymore
Certain known good project types fail to load properly
Known file types don't have syntax highlighting anymore
I can't add files to a solution because the option is greyed out
I can't add, remove, or update files to a solution due to an error
I can't add or remove projects to a solution due to an error
I can't open a solution due to an error
The debugger cannot launch, or attach to processes
I can't find any templates when I try to add a new item
I can't copy/paste due to an error
A DLL required by Visual Studio is missing or corrupt
Menus are suddenly empty
Something that I know should normally work, now does not work
How can I fix this?
(This question is meant to be a canonical close dupe for these types of questions)
Visual Studio is pretty reliable, and most of us using it aren't experiencing the issues you are. It's a pretty large and complex suite of components, though, which means problems are bound to occur.
First: Restart Visual Studio and, if that fails, restart your computer
The majority of small issues are fixed by restarting Visual Studio. Some of the ones involving connectivity or services can be fixed by restarting your computer.
If this doesn't fix your problem
There's no way to guarantee that something bad won't happen to a particular installation of Visual Studio. The ways a large, complex application can become misconfigured or damaged are too varied to mention.
The effort it would take to diagnose and track down every possible cause is great. Ain't nobody got time for that. The one reliable solution—which works almost every time it's tried—is:
Reinstall Visual Studio.
Go ahead, rest your eyes for a little bit. Come back when you've come to terms with this sad fact.
…
Resigned? Okay. We're going to go through the steps to fix your problem, starting with the lowest impact, but probably least likely to work, one first. While you are attempting to fix this, keep notes! Mentally, or write them down. If you get to the last step, you'll need them.
First, let's go the easiest route and return Visual Studio to its original state. We can do this by removing all extensions and by resetting all settings.
Open the "Extensions and Updates" dialog. If you can't find it, type that into the quick launch. If you can't find that, try ctrl-q. For each installed extension, highlight it and click the Uninstall button.
Next, let's reset those settings. Make sure you export them first!
From the docs:
To export your settings
1. On the menu bar, choose Tools, Import and Export Settings. Choose the Export selected environment settings option button, and then
choose the Next button.
2. Make sure that the check boxes for the kinds of settings that you want to export are selected and all other check boxes are cleared, and
then choose the Next button.
3. (Optional) Name your settings file, enter a different path where it should be saved, or both. By default, setting files are named
Currentsettings.vssettings and saved to %USERPROFILE%\Documents\Visual
Studio 2015\Settings.
4. Choose the Finish button.
You can import them later from the same location. Now, once you've saved your settings, go back and reset them.
Tools -> Import and Export Settings... -> Reset all settings
Having reset everything, try to repro your issue. Still breaking?
Heck.
There's no doubt that you need to reinstall. Let's go the easiest route and do a repair. Do the following:
Go to Control Panel > Programs > Programs and Features
Select Microsoft Visual Studio [whatever edition] [whatever year]
Click "Change"
Click "Repair"
After you've done this, try to repro your issue. Did it still happen?
Damnit, sorry.
If you want to try a different way, you may be able to do an "overlay" reinstall. Simply run the installer directly and select "install" (if this option is available to you). You can use your original media, but I'd strongly suggest you re-download the installer. This will overlay a new version over the old, without messing up your settings. After reinstalling, try to repro. Did it?
Aw hell. Here we go.
You need to try uninstalling/reinstalling. First, though, you might want to export your settings. You should have done this for step one of this answer, but if you didn't, go back and follow the instructions to do it now.
After saving them, repeat steps 1 and 2 (from the repair instructions) and this time select "Uninstall" instead of "Change". If your issue has to do with an external component, search for it in the list of other installed applications and uninstall it as well. If you're paranoid, uninstall everything Visual Studio related. They may be out to destroy you.
Now, reinstall Visual Studio. If you've found yourself at this point, you're in deep, so don't risk installing from your original media. Download a fresh, fully updated copy from where you originally got it. For example, if you got Visual Studio via your MSDN subscription, go there and download the ISO.
Now, having reinstalled everything, try to repro. Did it happen again?
F##&ing s#!t.
Now is the time to create a bug report. Go to Connect
https://connect.microsoft.com/VisualStudio/feedback/LoadSubmitFeedbackForm
Provide as much information as possible. You need to give them all the info they ask for in the form, plus details about the bug, how to repro it, and what you did to try and fix it. Remember those notes I told you to write down? Bust them out now. I'd strongly recommend you mark your issue public, as it may be found and commented on by others with your problem.
Within a day you'll get a response. They will probably want you to turn on Visual Studio logging and repro the issue. I won't tell you how to do this here, as they will give you exact instructions for the version of Visual Studio you are running. Follow them and reply as soon as you can.
There will be one of three outcomes from this process:
They will tell you that you're doing it wrong
They will discover an outside actor causing the issue
They will discover a bug
For #1, stop doing that, and you're done. For #2, they'll probably tell you to uninstall the bad actor (e.g., remove a plugin) and go tell the people responsible about the bug (don't slack--do it). For #3, they'll triage the bug and it will be fixed sometime later. It's likely they will suggest workarounds that will at least get you moving again, if it's a true bug.
And that's it. Now, go forth and reinstall Visual Studio!
I got Team Explorer Everywhere so we can use TFS on the Mac Mini we got to test Iphone apps. Since we're using XCode for phonegap, we need to use the commandline program and it is giving me a lot of grief.
What I've done so far (Listing out for anyone who stumbles on this so they can use it):
-Downloaded the trial (free)
-Set the path using PATH=$PATH\:/FOLDERLOCATION
-Accepted EULA and got trial product key... for command line program (tf eula/tf productkey -trial)
-Set up workspace:
tf workspace -new WORKSPACENAME -server:http://SERVERNAME:PORT/FILEPATH -comment:"WORKSPACENAME" && prompted for username -> domain -> password
-Trying to setup the folder path (Fixed):
tf workfold -map SERVERFOLDERPATH LOCALFOLDERPATH -collection:http://SERVERNAME:PORT/FILEPATH -workspace:WORKSPACENAME && prompted for username -> domain -> password
-Make sure I can check out/check in (On hold):...
The error I'm getting right now is "An argument error occurred: First free argument must be a server path." This is what I've been following ever since I got the path set, but I think the versions are different because mine doesn't seem to be set up the same. Any help at all would be appreciated, and I'll keep up with the post as I figure parts out because there doesn't seem to be much online that I can find on TFS on macs.
Update: As normal, I'm an idiot. Have to put the options at the end of the command and have to have the serverfolder path as the first thing after -map. Now I just need to figure out how to use the damn thing. I'll post any other questions I have and try to get all the correct commands up for the selfish reason of having them somewhere in case I forget them later.
Update 2: The mapping hasn't worked out as well as I'd hoped, it seems a combination of my unfamiliarity with Unix/Mac file systems and some settings being missing is keeping me from using 'tf get' to load all of the test data I was trying to get. I'm planning on trying again after I get the location of where my boss wants the data saved and after I can look into something that would save the workspace so it won't say that it can't find the map path every time...
It looks like you're setting up your workspace and some working folder mappings just fine, after the edit. If you're having problems doing a tf get after this, then there are some common problems that might be occurring. TFS workspaces can be a little bit opaque and having a better understanding of them can sometimes help you understand where the problem is:
Team Foundation Server requires a workspace to be configured before you can get files out of source control, edit them or check them back in. A workspace basically simply contains working folder mappings that map your local path(s) to server path(s).
Workspaces are stored on the server and are uniquely identified by your computer's hostname, your username and the workspace's name. A cache of this information for the local host is saved on the client. This implies:
If you remove a workspace on the server, your workstation will be unable to connect.
If you remove the cache, your local computer will not be able to identify the workspace based on working folder mappings until the cache is rebuilt (which happens every time you connect to the server.)
If you change your username or local workstation's name, you cannot access those workspaces.
(Note that very early versions of the Teamprise command line client had certain issues on Mac OS that made identifying the local workstation name difficult. This is fixed, however, in Team Explorer Everywhere.)
Because you can have multiple workspaces for a single server on a single workstation, you can't always simply provide server paths to tf commands, since server paths are ambiguous. ($/ exists in every workspace, for example.) So the command line client resolves paths based on the current working directory and/or the arguments provided. Meaning that you can run tf get foo.txt if you're in a working folder, or you can run tf get /tmp/foo.txt if /tmp is mapped.
One more point - the configuration data for Team Explorer Everywhere is shared between the TFS plug-in for Eclipse and the command line client. So if you're more comfortable using a GUI to set up your workspace(s), you can do that and then use the CLC as you see fit. You don't need to be a Java programmer to use Eclipse - simply download Eclipse and install the TFS plug-in for Eclipse into it, and select Window > Open Perspective > Team Foundation Server Exploring. After that, you'll have the full GUI Team Explorer experience and this perspective will be restored when you open Eclipse, so you won't even need to worry about the Java IDE bits if you don't want to.
We have a an ASP NET MVC website solution which only one out of three devs on the team is able to publish to the live server. When I, and another colleague, attempt to publish the site from VS 2010, the output window will display an error:
Unable to create the Web site
'\blah'. The path '\blah' does not
exist or you do not have access. The
specified path is invalid.
This points to a logon issue which my account, but the developer who can publish the site is a member of all the same user groups as me. As a long-shot, we gave Everyone full access to the folder, but this did not resolve the problem.
Can anyone suggest a more detailed way to try and figure out why we cannot publish the site? There must be a permission set somewhere that is allowing my colleague to publish the site from Visual Studio.
I had this problem and racked my brain trying to resolve it so I wouldn't have to copy the publish files to a remote server manually. I spent a great deal of time actively trying to get this to work.
Here's how I solved the problem: I went to File>Open in Visual Studio 2010 Express and navigated to the remote server (\\255.255.255.255\folder1\folder2\folder3 and so on). Right away I was challenged for a User Name an Password. I entered the credentials for the REMOTE server, checked the box to 'Remember my credentials'. I immediately tried to publish and voilá - it worked like a charm.
I hope this saves a lot of people a lot of time.
I had this issue - certain members of our team were able to publish directly from VS2010, whereas for some reason I was always getting permission denied errors, even though we were all able to connect to the server we were trying to deploy to. I fixed it in the following way:
Go to "Server Explorer".
Right click "Servers" and go to "Add server..."
Type in the name of the server you are trying to connect to, and then click on "Connect using a different user name..." - put the credentials for logging into the server in here.
Click OK and wait for it to add the server.
Now try and publish to that server and it should be ok...
Not sure why I needed to do this and others were able to deploy without adding the server in this way... remains unexplained.
According to the comments below:
You may need to restart Visual Studio in order for this to take effect.
This should also work for newer versions of Visual Studio
Faced the same problem today. In my situation I had to close VS2010 and open it NOT as an admin and it worked without any problems.
This got me for a long time...Go to Project - Properties and select the Package/Publish Web tab. Under the header "Web Deployment Package Settings", there's a ellipsis button that you can use to map to the location you want to publish. You will be asked for your credentials during that process.
Are you using web deploy (right click and choose Publish)?
Have you tried copying the ProjectName.Publish.xml file from the one machine where you can publish to the other two machines? The login credentials for publishing are saved in this file.
In IIS can you check to see that all users/groups are listed under Management Service Delegation in IIS Manager? It is listed under the Server node in IIS. Alternatively you can give all administrators access by clicking on Edit Features from the side-menu and checking Allow Administrators to bypass rules.
You could also check under IIS Manager Permissions for the individual site to see if the person that can publish is listed under there and you are not.
I just recently setup MSDeploy access on my server and found the following two tutorials helpful:
http://william.jerla.me/post/2010/03/20/Configuring-MSDeploy-in-IIS-7.aspx
http://code-inside.de/blog-in/2011/04/03/howto-setup-of-webdeploy-msdeploy/
I have also found that mapping a drive to the UNC location can be a work around.
#soupy1976's solution has also worked for me.
I can not explain why one day it will work and one day it won't
Frustrating....
I'm using VisualSVN with my Visual Studio 2008 and I have to run some sort of commit monitor in the tray area to see if the local copy of project is out of date.
I have two problems with that:
I hate to have it in two places, I want to see that as an icon in my VS,
The commit monitor software keeps an eye on several projects, when I work on project 1 (which VS knows about), I'm not interested in other projects.
I couldn't find any addons for Visual Studio to do that and was wondering if anyone knows about anything good.
Generally, you have 2 options (besides running commitmonitor as you already do):
run update before you start to change something
ignore it all and merge with any updates when you want to commit.
SVN's really designed around the 'wait until you're ready and merge it all together' model, as there's no guarantee that even if you update your working copy immediately before starting to modify it, someone won't commit changes before you've had a chance to commit. So, let the system do the work for you.
The ultimate alternative if you are worried about conflicts is to use the svn:needs-lock property which means you will have to get a lock on any file you modify before modifying it, and you won't be able to get a lock on a file someone else is modifying.
You might like to ask the VisualSVN people if they'd add an option to check the repository when a project is loaded by VS (or run AnkhSVN and implement this feature yourself).
Work has started in AnkhSVN in this direction, we started to implement the 'Synchronize View' that's also used in Eclipse/Subclipse. The things still missing are: Scheduled checking of the repository, and maybe a notification inside VS to tell you that something has changed.
Right now you can manually refresh this view to see local and remote changes (and merges which can be potential conflicts). Patches are welcome to extend this feature :-)
I'm assuming VisualSVN is your "server" (even if running on the same machine).
AnkhSVN is a good Visual Studio Integrated SVN Client.
I just added xUnit to our test project (for the Asserts, we're still using MSTest as the framework) and immediately the test runs refused to execute any of the tests. This is the error message:
Failed to queue test run '{ .... }'
Test run deployment issue: The
location of the file or directory
'...xUnit.dll' is not trusted.
It took me a few tries to find the answer in Google, so I'm putting it here in case anyone else runs into the same problem. A detailed description can be found at this blog posting.
Basically, the fix invovles right-clicking on the dll file (xunit.dll for example) in Windows Explorer, going to Properties, and clicking "Unblock" at the bottom of the tab next to the 'Security' text. It seems that Vista / Windows 2008 will automatically mark assemblies that come from other machines or the internet as unsafe.
As a couple commenters have mentioned, you may also need to restart Visual Studio for this to take effect.
In my team we had the same problem.
Your solution didn't work, but this post by Charles Sterling did help.
We used the following line:
caspol -machine -addgroup 1 -url file://\\server/share/* FullTrust -name DevShare
After having this issue and burning hours trying to get "Unblock" to stick longer than a few minutes and/or figuring out caspol to no avail, I finally found a little tidbit via Google that the assemblies will be blocked again the next time you build or rebuild the project, since they're re-copied from their original source location. (I guess I never noticed that this happened before with references assemblies, but anyway...)
My fix for this was the following:
Copy all the needed DLLs to another
spot for safe-keeping
Remove the
references in Visual Studio
Physically delete the DLLs in the
bin folder
Unblock the DLLs
individually in the spot where they
were copied off
Add the references
back in Visual Studio from the
holding spot
Every subsequent build or rebuild worked fine afterward.
Running on an XP machine (even with .NET 3.5 SP1 installed) I was not able to get any of the other solutions listed here to work.
However working from the same post by Charles Sterling that Davy Landman references, I finally succeeded with this variation:
Run the .NET 2.0 Configuration tool (Settings... Control Panel... Administrative Tools... .NET Framework 2.0 Configuration)
Click down to "My Computer ... Runtime Security Policy ... Machine ... Code Groups ... All_Code"
Create a new code group with membership condition of "Zone"="Local Intranet" and assign the permission set "FullTrust"
Restart Visual Studio
After these steps I am able to run tests, including after restarts and rebuilds.
EDIT: as described in this answer, you may need to install the .NET SDK (which is different from the .NET framework) in order to have the .NET 2.0 Configuration tool on your system.
I had the same problem with moq. But would not 'unblock'. Every time I unblocked it, it was still blocked!?!?
I had to unblock the original zip file I downloaded. Then copy the DLL from the zip file again. It work after that.
It may seem really obvious now, but when I was clicking unblock the file was set as read-only.
Only after un-checking that attribute, applying, then selecting unblock did I actually get this working.
Give that a go.
:)
PS: I also deleted all the old dll's in my bin folder, just to make sure Visual Studio wasn't picking up the old one.
I had the same problem with downloaded DLLs blocked by Vista.
You need Administrator rights to get the "Unblock" button on the file's Properties.
I simply replaced the DLLs with the latest version from source control (TFS) where I had committed them before.
Go to file
Right click and select Properties
On the first Register click on Allow
I also tried opening the file in notepad++ and renaming it.
Slightly different approach, but it worked for me. The local file system then think it comes from the same machine.
It's not just the moq.dll that needs to be unblocked. The latest zip file includes an moq.xml and moq.pdb file - referencing the dll copies these other two files to the bin folders as well. If all three have not been unblocked the tests won't run, I found.