TF237090: Does not exist or access is denied - workitem

I created a new work item type, i'm trying to import it in my tfs 2012 project but i'm getting an error TF237090: Does not exist or access is denied. I can succesfully import an existing workitem after changes but not a new one.

I tried this in VS2012 by importing WIT via the Dev Studio Tools->Process Editor->Work Item Types->Import WIT. If I recall when I ran into this issue before it was because someone had the a work item open (in this case it was a test case).

Summary
Ensure that the version of witadmin being used for import & export of WITDs corresponds with the TFS Server version
Ensure that the version of the MS VS TFS Power Tools being used corresponds to the TFS Server version
Background
I have multiple versions of Visual Studio installed, including versions 2012 (v11.0), and 2013 (v12.0). However, our TFS Server version is 2012.
I had this problem when running witadmin importwitd from the command line. It seems that the tools used to export and import the Work Item Type Definitions (WITDs) need to be the same as the TFS server version. Hence, when running from the command line, for running with TFS 2012, the witadmin command should be run from the C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE directory, not the v12.0 or any other version.
Once I realized that I may have been trying to import a WITD XML file that had been exported from a different witadmin version, I re-exported (from the server) in the correct version - use witadmin exportwitd - then made my changes, and re-imported.
One annoyance is that the Work Item Type Editor for 2012 didn't seem to care that the XML WITD file that I imported came from a different version.
Insight gained from here: http://social.msdn.microsoft.com/Forums/en-US/399b4c50-fbaa-43f6-a0f5-88129f9b2ed8/tf237090-does-not-exist-or-access-is-denied-when-usint-witadmin-importwitd?forum=tfsgeneral

In my case, I was able to change the Task WIT template of a particular project using TFS Process Template Editor Extension in Visual Studio 2017, but when attempting to change another project it was failing with message:
Microsoft Visual Studio Failed to save the 'Task' Work Item Type to the server.TF237090: Does not exist or access is denied.
I am a member Project Collection Administrators (at higher level - collection) and I had most of the permissions needed to perform most of the changes required, including Team Admin ('Team Project Name' Team - Administrators).
Turns out that I was not part of the 'Project Administrators' within that particular team project. All I had to do was to navigate to the Admin area, under Security tab of that particular project and add my username to the Project Administrators group.

Related

Visual Studio 2015 - Add New Item: "No items available for Templates"

The ADO.NET Model Templates are missing in my version of VS2015. I have tried installing the SQL Server data tools and re-installing the EF Tools as per suggestions found elsewhere but neither have helped. Does anyone have a solution for this issue?
Many thanks
I fixed the same problem in the following way
got to the Control Panel -> Programs and Features -> Right click on Visual Studio 2015 -> Modify -> (tick the feature "Microsoft SQL Server Data Tools" ) and Update
give it a try
I was getting the No items found message when attempting to simply add a new class to my project, and managed to fix it using the steps provided by this blog post by Kevin Wilson
Close Visual Studio
Remove (and backup) the following directories from your Visual
Studio installation.
VisualStudioInstallDir\Common7\IDE\ItemTemplatesCache
VisualStudioInstallDir\Common7\IDE\ProjectTemplatesCache
Run command prompt as administrator, and navigate to the Visual Studio directory, e.g.
cd C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7IDE
Run the following command to regenerate the item and project template caches
devenv.exe /InstallVSTemplates
Restart Visual Studio, and if everything's worked, your class & project templates should all be working normally again.

MSBuild Errors for Database Project on TFS server with VS 2013 shell

Continuous Build Database Project fails when building on TFS server. We have Visual Studio 2013 Shell (Integrated) installed. There does not appear to be a way to install SQL Server Data Tools 2013 thru' Tools > Extensions and Updates... menu.
The redacted error is below...
C:\TFSBuild\XXX\XXX\Database_CI\Sources\Database\XXX\XXX.sqlproj (126): The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
Has anyone experienced this? Is there a solution or work-around? Is SSDT available for VS 2013 Shell for SQL Server 2014?
I have recently installed the Visual Studio Shell (Isolated) and (Integrated) on our build server and it does not include the SQL Server tooling components. I found out that SQL Server tooling is built in to the following versions of Visual Studio (see here):
Express for Web,
Express for Windows Desktop,
Professional,
Premium, and
Ultimate
I would recommend installing at least the Professional version and then you should get the SQL Server Data Tools components that are required for building.
SQL Server Tooling is now built into the above listed versions of Visual Studio 2013 (SSDT and Visual Studio versions) and the latest March update of Visual Studio 2013 now includes SQL Server 2014 support (SQL Server Data Tools for SQL Server 2014 is available.)
To force your build to use the correct version of MSBuild set the Process - Advanced - MSBuild arguments = "/p:VisualStudioVersion=12.0" (without the quotes) as shown.
You can download SSDT for VS2012 here and that should get the database pre-reqs on your build server.
I do see mention of "Sql Server Tooling in Visual Studio 2013" on this landing page, and I think it implies these tools should be available with the shell, so if you could, check to see if you have that targets file somewhere on your build server.
Go into C:\Program Files(x86)\ and do a "dir Microsoft.Data.Tools.Schema.SqlTasks.targets /s /b" and see if something comes up.
Right now it's hard-coded to this location:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets
You might want to see if the file already exists, but in another location, like in an "v12.0" folder instead of the "v11.0" subfolder.
EDIT
Actually, what's the value on line 126 of your .sqlproj?
If it says this:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" />
Change it to read:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" />
Then have everyone test it using diagnostic logging, then gather the logs and compare them to make sure that version is consistent so you can start phasing out the legacy bits.
I had the same issue and fixed it by downloading and installing the following
dacframework.msi
SQLDOM.MSI
SQLLS.MSI
SQLSysClrTypes.msi
from here:
https://www.microsoft.com/en-au/download/details.aspx?id=42295

Shell Extension : Not showing in Windows Explorer context

I have Windows 7 Professional x64. I have Visual Studio 2010 Premium and Visual Studio 2012 Premium installed on my machine.
I installed TFS Power Tools Decemeber 2011. I restarted my computer after successful installation. I then checked out a folder from TFS 2010 but the TFS menu items in Windows Explorer context menu do not appear when i right click on the folder.
I even reinstalled it by uinstalling it, restarting the pc and installing it again then restarting it again but same issue.
I have followed the instructions outlined in here:
TFS Power Tools: Shell Extension : Context Menu Quirky and TFS Icons on Files/Folders missing
But same issue same issue occurs. Would anyone know what else i can do to get the TFS menu items to appear in the context menu please?
Thanks in advance,
I am not sure if this would help or you are willing to use a new version but I had the exact same environment and issue with you.
What I had done is that I uninstalled the old TFS Power Tools ( listed with a "Microsoft Team Foundation Server" prefix and/or "Microsoft Visual Studio Team Foundation Server" in Control-Panel/Programs-and-Features ) and install a newer version which is RTM. You can download them at http://www.microsoft.com/en-nz/download/details.aspx?id=35775 and install the following in the same order listed below
Team Foundation Server 2012 RTM Power Tools.msi
Visual Studio Team Foundation Server 2012 Update 1 Power Tools.msi
Visual Studio Team Foundation Server 2012 Update 2 Power Tools.msi
Close Visual Studio before you start then restart after installing, you should see your context menu afterwards together with the green arrow that indicates it is in TFS
Here is a screenshot of it
Also please take note that after installation this would not happen instantaneously as advised on this post: TFS Power Tools: Shell Extension : Context Menu Quirky and TFS Icons on Files/Folders missing
It sometimes takes a while for the TfsComProviderSvr.exe to check if
the local folder is a workspace and register the shell extension.
So this depends on many variables, your TFS server speed, your machine speed and your network speed. In my case I left it overnight to fully show everything.
Windows has a limit on home many overlay icons it can support. This started happening to me after i installed google drive, one drive, and dropbox and the TFSOverlay got pushed down to the bottom in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer \ShellIconOverlayIdentifiers
You can fix it by either
Uninstalling some of the overlay apps. (Eg: remove Google drive
or Dropbox)
Rename the TFS folders in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer \ShellIconOverlayIdentifiers to start with numbers so they take priority (Eg: "1TfsOverlayAdd" , "2TfsOverlayEdit" etc.).
Also there is usually a delay for the green icons to appear in the folder explorer, so be patient.
I was having the same problem and just I executed this file:
C:\Program Files (x86)\Microsoft Team Foundation Server 2012 Power
Tools\TfsComProviderSvr.exe
After a few minutes the menu appeared.
This problem also occurs when you are running Visual Studio under different credentials (i.e. an account with Administrator privileges) than the logged on user. Logging on as that same user displays the ShellExtension correctly. But that's just not an option here...
I have not yet found a solution. It would be a nice feature to be able to set some options for TfsComProviderSvr.exe, so that one can let it watch workspace folders for a different 'Team Member' than the logged on user...
I've tried running Explorer.exe with other credentials, but that does not spawn a new TfsComProviderSvr.exe. Starting it by hand with the different credentials also does not seem to work. An instance of TfsComProviderSvr.exe is always (re)spawned for the currently logged on user.
Forgive me for sharing the obvious, but I had a similar issue, and in my case it appears that the default selected installed features were different than I expected.
I reran the installer using "Modify" instead of "Repair" and confirmed that the Windows Shell Extension feature was selected for installation:
I'm running a similar environment (VS 2010 Shell with VS 2013 Professional). Perhaps that impacts the defaults.
Here is the Power Tools Installer that I used.
I had a similar issue, I ripped off old the version, gave me some issues as you have to stop the TFS process and the explorer process but you can always restart explorer again once the old version has been uninstalled.
Then I restated my machine.
Installed latest version: http://visualstudiogallery.msdn.microsoft.com/b1ef7eb2-e084-4cb8-9bc7-06c3bad9148f ( version 11.0.60506.0 )
Restarted my pc again
Navigated to a source control folder and all TFS icons and shell extensions now started to appear.
Bottom line, the latest version worked for me, did not have to fiddle with reg'values at all.
Here's how I fixed mine. I had installed Visual Studio 2015 and installed TFS Power Tools for VS 2015. I also installed Visual Studio 2017. I generally use VS 2017 and had attached to TFS there. I hadn't attached VS 2015 to TFS and the power tools menu would not show up in explorer. I finally realized that when they say you have to have the same version of Visual Studio installed that you ALSO have to have that visual studio Team Explorer connected to TFS. You don't have to use it beyond that, but it must be connected using the dialog, like you see here.

Visual Studio error when trying to open dbproj files

I have Visual Studio 2008 Database Edition, and everything worked great until the first time I tried to load a .dbproj file. These database project files work for the other developers I work with, but when I try to open it, I just get an error message "Object reference ot set to an instance of an object."
It's probably the same problem this guy is having, although he didn't do a good job of describing it and has no solution.
Every other kind of project file loads and builds and runs normally. dbproj files all generate this cryptic error. I just tried a fresh removal and reinstall of Visual Studio 2008 DE to no avail. Could this have something to do with my SQL 2005 installation? (This also works normally through SQL Server Management Studio.)
**
UPDATE
**
Probably even more importantly, this same error occurs when I try to make a new dbproj file. Every other type of project can be created no problem.
You need to tell Visual Studio the correct instance of SQL Server to use for validation.
Tools>Options>DatabaseTools
Change the settings in "Data Connections" and "Design-time Validation Database" to reflect the correct instance.
After many failed re-configurations and re-installations, a member of my team discovered the problem!
Under Tools > Options > Database Tools > Design-time Validation Database, there is an option to set your SQL Server Instance Name. Visual Studio automatically picks this when it's installed.
The key is that Visual Studio doesn't necessarily pick the right one. I happen to have 3 SQL server instances on my machine. SQLEXPRESS (a 2005 instance that Visual Studio installed alongside itself), SQLEXPRESS2005, a 2005 instance I installed, and SQLEXPRESS2008, which I also installed.
Visual Studio had configured itself to connect to the SQLEXPRESS2008 instance, even though it only supports SQL2005 dbproj files by default. By opening this dialogue, and updating the server instance name, the error no longer appeared and I was able to open dbproj files:

How does TFPT.exe find what workspace to work in?

In using tfpt from the command, I'm getting the error:
PS D:\Main Line> tfpt uu /noget
Unable to determine the workspace.
Here I'm trying to use the Undo Unchanged command, but I've seen this error with other commands too. The path I'm at is the exact path that is mapped in my TFS workspace. I also tried this which doesn't work either
PS D:\Main Line> tfpt uu /recursive /noget 'D:\Main Line'
Unable to determine the workspace.
I thought it was just using the current path to figure it out, but I can't get it to work right. Does anyone know how this works?
I ran into this same issue, I found the answer at the bottom of the page in one of the help files that came with The power tools. (TFPTCommandLineTool.mht)
Errors
TFPT Error: Unable to determine the workspace
When running tfpt using a command that works with Version Control, you may receive one of the errors:
Unable to determine the workspace
Unable to determine the source control server
Solutions:
Run tfpt.exe from within a directory that is already mapped to Team Foundation source control.
Update your local workspace cache using the tf workspaces command. The tf.exe tool is available in the subfolder Common7\IDE of your Visual Studio installation folder. If you launch a Visual Studio command prompt, you can then run the following command (which depends on your versions of TFS/VisualStudio - you should use the version that matches version of TFPT you are using, e.g. if you have TFPT for VS2015, use TF from a VS2015 command prompt):
VS 2008-2013 / TFS 2008:
tf workspaces /s:serverURL
VS 2010-2013 / TFS 2010 (and probably later versions as well):
tf workspaces /collection:collectionURL
VS 2008 / TFS 2010 (and probably later versions as well):
tf workspaces /s:collectionURL
If you have recently installed Visual Studio 2012, you might have to connect it to the same TFS server/collection you were using in Visual Studio 2010.
When using tf workspaces /s:serverURL make sure you use the right tf.exe!
I had the same problem and was stuck because I used the tf.exe from:
\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE
and not the one from:
\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
For Visual Studio 2017 users
I had the same problem when trying to run the tfpt command line on a fresh machine installation with VS215 and VS2017 installed. The latest version for the tfpt tool at the time of writing is from TFS Power Tools 2015. That means the local workspace mapping has to be loaded in VS2015 first before the tfpt tool can find the workspace.
Since my team is using VS2017, I only did the workspace mapping in this Visual Studio version. When I opened the VS2017 developer command prompt to use this tool, I got the 'Unable to determine the workspace' message.
To solve this I opened VS2015 and connect the Team Explorer to the TFS server. It immediately recognizes the workspace mapping that was made under VS2017. After this the tfpt tool works correctly under VS2015 and VS2017 developer command prompts.
I tried all of this and still i got the same error. The error is generic enough to represent multiple issues, i guess..
re-installing TFPT from
https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f
fixed the issue for me.
Actually, although I believe that in some cases these workarounds may fix things, they do not work in all cases. And I strongly suspect that ultimately this points to what could be considered a bug somewhere in the PowerTools code. The reason I say this is that the tf workspace command has no problem detecting the workspace on my machine from the VS Command console, but from that very same console with all of the same path info, TFPT cannot detect it on my lap top no matter what I try. I just got this laptop and installed VS 2010, 2012 and 2013, along with the respective Power Tools installs, and pointed to a suite of projects that currently spans several TFS 2010 and TFS 2012 instances. Because of this many-to-many relationship, I suspect there is an incorrect assembly reference somewhere, some combination of factors, GAC, Path, Environment Variables, VS Installations, TFS repositories. In each VS version I attempted to run the TFPT 2010 executable from the VS 2010 Command, and so on with the remaining versions, and tried the above workspace cache updates in all their forms... nothing. But using the same project I connected from an old server with VS 2010 and TFPT 2010 installed and ran the same command perfectly. So I think it has to do with what is running on your system, and in the future I will be much more skeptical about running the different versions side-by-side.