I've been able to edit and continue for more than a year. I don't know what unfortunate mistake I've made but I'm now not able of editing the code and continuing anymore, as when I try I get the "Changes are not allowed in the following cases".
I've been googling and changing settings for more than half a day straight now! x86, enable and disable, repair VS, 2015 and 2017 versions, check the project settings... As far as I can tell I've touched every single switch I can think of and I still can't edit and continue!
I've noticed though that I can edit and continue on a simple console program (Console.Write and .Read sort of thing) but not on a simple MVC project (the one that comes with the MVC scaffolding) so I'm now thinking is something to do with MVC.
Any thoughts? It's happening even with projects that I could edit and continue with in the past!
Following Karthik recommendation and https://stackoverflow.com/a/27672935/3397630 I just had to remove COR_ENABLE_PROFILING from the system and user variables!
There are a few more similar entries like COR_PROFILER, CORECLR_ENABLE_PROFILING and CORECLR_PROFILER but I left those there.
Related
I am scripting a mass rename of ~100 TFS 2018 U2 projects by using the REST api, as a setup event to the project deletion that will occur in 2 weeks.
So, I'm renaming ~100 projects from foobar to TODELETE-foobar.
The rename is going great using the PATCH against /_apis/projects/$($project)?api-version=4.1, but I'd like to be able to get rid of the automatically created alias that lets TFSCOLLECTIONURL/foobar redirect to TFSCOLLECTIONURL/TODELETE-foobar
Nobody should be using these old projects, and getting rid of the redirect will help me ensure that they're not - this helps me cover employees that ignore my notifications.
Thanks!
This is an X/Y problem. You have a problem:
People shouldn't be using legacy projects that are scheduled for deletion.
Your solution:
Break any existing links to the projects that shouldn't be in use.
However, as you're seeing, that's not an effective way to manage the problem, because people ignore or otherwise miss notifications.
The correct solution to your problem is a lot simpler and removes the possibility for someone to miss the memo that they shouldn't be using a project:
Make projects that shouldn't be used anymore read-only.
Bonus points: Put a link on the project's homepage via a README.md file that points to the place they should be working.
I want to be able to see (in VS2013 UI) till which change-set I updated my files.
The reason I ask this is because of the following scenario:
I created a fix, checked it in and continued working on something else. One day later, my colleague is testing the bug I solved but found it unsolved. Next, I tried to reproduce it at my machine but was not able to do so. So I wondered whether my colleague got the latest version before starting to test, he was convinced he did, but we cannot find a way to see on what change-set he is.
It is important for us to know this information without getting the latest version and retest it. Since the testing procedure for this bug takes quite some time, and time is valuable.
I'm quite new to TFS and we just switched from SVN to TFS. At SVN, using tortoise, the revision of the local working copy was highlighted, so the user knew which revisions he missed or was at.
I would like to be able to get this same information via VS2013.
I searched the web and found this other question but it uses the command line and I want to see it in the UI. Beside that, I couldn't get the command to work.
The question: Where can I find the number of the change-set in the VS2013 user-interface, my local working copy is on?
One place I know of is in the source control explorer window of Visual Studio.
1: right click a file and go to Advanced->Properties
2: Under the general tab you will see "Workspace Version #" and "Latest Version #"
In the Source Code Explorer you should have a column for "latest". This will tell you at a glance if you have the latest or not.
Last week I upgraded our TFS 2012 Server to TFS 2013. I read the MSDN documentation first and I also followed the documentation as I performed the upgrade. Everything seemed to go ok.
After the upgrade I ended up with 7 or so Team Projects that the wizard couldn't configure, for whatever reason, and needed manual configuration.
I noticed this week that ALL of the work items under one of my Team Projects are missing. Gone. Like even if I select Team|Go To Work Item and enter in a known Work Item Id, I receive an error that the item is either missing or I do not have permission to view it. I'm an Administrator on the TFS server and I'm the TFS Admin, so I highly doubt permissions are the issue.
I remoted into the server and launched SSMS to explore the raw data. I know for a fact Work Item 450 is missing (it's the only Id I remember at this point). I selected the TOP 1000 from WorkItemsAre, which seems to be the table that holds the Work Items (?). There is a gap in the Ids, I see 1-448, then the numbering picks up again at 457. So, somehow my Work Items appear to have been deleted. I stopped there, I assume there are more gaps since I'm missing more than 9 items.
Now I haven't gone through every one of our Team Projects. I've only touched 3 of them since the upgrade. Thankfully the largest, most active Team Project, with the most work items/version history seems to be intact. I'm not sure if any other Team Projects are missing their Work Items too.
Has anyone else experienced this? Does anyone know if there's some "secret squirrel" way to recover these missing work items, or have they been hard deleted and are gone for good (other than looking through tape backups of the server).
Any advice would be appreciated.
I already migrated to TFS 2013 from TFS 2012.
The problem of manual configuring the project may occur when you have customized work item types in TFS Project Templates. Did you customize your project templates?
Although, I can hardly believe that work-items getting hard deleted from TFS. This issue may occur probably because of archiving during migration. The workitems that TFS upgrade wizard may not have "understood" during migration/upgrade, might be archived and moved to another table in database Tfs_DefaultCollection.
You may want to consider that. I am not sure if that may be the case, but this happened when we migrated from TFS 2010 to TFS 2012 because we had many custom work items in TFS 2010. Hence we had to standardize templates before migration using powershell. But we lost some amount of history.
Hope that sparks some idea.
In TFS I have a started a Scrum project, but I want to add some fields to a Work Item.
So I'm following this tutorial on how to add Estimate and Completed work hour fields to a Work Item.
I added one field in the layout, like shown in the tutorial. But when I try to save it I then get the following error:
TF237113: You don't have enough permissions to complete the import operation.
I think I have all the needed permissions. I changed all my user permissions and also the permissions I have in the TFS project that I'm working on.
But so far no luck. Even when I try to add a field in the Layout tab that already exists, then it still gives me that error. Anyone any idea what I can try to solve this error?
It looks like you're using Visual Studio Online (Since I can see that you have a Windows Live ID), Visual Studio Online doesn't support process template customization at all at the moment. This is due to the fact that they release new versions of the service every 3 weeks or so, and having to consolidate and test all customization across all projects would be a major pain.
We have recently migrated to TFS 2010 using the MSF For Agile process template and we make use of such reports as the Burndown, User Stories progress etc. Up until 13/10/10, our warehousing worked perfectly and all our reports displayed upto date data. However, after this date, the reports started displaying old data and on looking at the status of the warehousing jobs using the GetProcessingStatus() method on the WarehouseControlWebService, we can see that the Work Item Tracking Sync job seems to be stuck in the 'Running' state.
Indeed, when you put a profiler on the database, you can see the same stored procs being called again and again, with the same parameters, as if it is stuck in a loop. While this is happening, the CPU usage is 50% and above. It stayed in this state for over 24 hours before I decided to kill it.
There is nothing particularly crazy about our setup - we did a clean TFS install and imported work items from TFS 2008 using Excel. We also have a custom work item template 'Support Ticket' which our support team use to log calls from customers. All importing was done with the proper TFS command line tools or Excel.
Has anyone experienced anything like this before? I have seen a couple of posts where people have had similar issues but not seen an answer.
I am delighted to inform everyone that we managed to fix it! The issue was a rogue work item (Bug) which had a link to a Task which did not exist. I am not quite sure how this happened but can only assume it happened during our work item import from TFS 2008.
We only noticed this because, as a last resort, we were going to create a brand new Team Project Collection and Team Project, and import all our work items into it and see if the warehousing worked there. However, when we viewed the 'All Work Items' query as a tree view in Team Explorer prior to the import, one of them was highlighted in red with an exclamation next to it saying the referenced item does not exist. We simply deleted them item using 'witadmin destroywi /collection:http://tfs2010:8080/tfs/<> /id:1571' and then magically the warehousing worked again. Marvellous!
If this post helps even one person then I am a happy man as this has caused us much heartache over the past week. Although we have managed to overcome the issue, it can't be denied that Microsoft's error handling in TFS leaves a lot to be desired.
Yours
Dan