I've got files in TFS that are not showing in the solution explorer of VS 2010. Another developer committed the files to TFS. I can see the files in TFS, and they are even being copied to my local directory, but they aren't appearing in the solution explorer.
What am I doing wrong?
Also, when my coworker committed his changes, it is marked as changeset 99. When I look at the hierarchy of the main branch (where he committed the changes to), it says the latest version is changeset 9 (which is the changeset that created that branch). Why does the hierarchy view say its latest changeset is 9 when clearly the latest changeset is 99? Am I using the tools incorrectly?
Thanks
This is a 'known' bug in VS/TFS. If you checkout a file from the 'Solution Items', VS goes and removes the file from the project.
To show files on the solution explorer you have to add files to the TFS and you have to update your project files also. You can try Show all files button on solution explorer.
For changeset number issue - pres Ctrl+G on the Source Control Explorer. Enter number 99 or click Find for more search options. Check changeset details or track changeset. Maybe you are checking wrong project collection or it is a bug.
Related
I created a SSIS package using SQL Server data tools 2015 a week back.
And today i opened the package and it just shows the blank screen.
I read about this issue here and it seems that was the defect in earlier versions and it is fixed.
Did anyone face this issue in data tools 2015? How can i fix it and save my package?
1) While the package is opened with the white page, rename it in the solution.
2) Save the package and close.
3) Rename the package back original name (while package is closed). This rename will open the package and hopefully set it back so that you can edit it.
This has worked for me, hopefully it will work for others.
All white on open? Just happens from time to time, the stuff is there just close and reopen Visual Studio always makes it come back for me.
But if not you could always find the dtsx file under it all in your users folder:
C:\Users\<yourusernamehere>\Source\Workspaces\<Projectworkspace>
copy it and then pull it back in by right clicking the SSIS Packages folder in Solution Explorer and add existing package see if you can see it then.
Tim's answer above helped but didnt work for me. Instead this worked in Visual Studio 2015:
Close the solution
Move the .dtsx file that will not open to another folder (ex: C:\Temp)
Rename the .dtsx file to the name you want
Open the solution - you should get a message that the package is missing.
In Solution Explorer, right-click on "SSIS Packages" and select "Add existing Package"
Package Location should be "File system". Click the "..." button and select the moved and renamed .dtsx file. click OK
The .dtsx file should now be added in the solution correctly named - and open for editing.
The rename and reopen trick worked for me. I also tried another way. I closed Visual Studio and then located the .suo file under the .vs folder. I deleted that and then reopened and the file reloaded.
I hope that isn't too dangerous an approach; it stops git changes being made when the rename is performed
I have tried the trick to rename the package. It works as long as I keep a new name, but when I rename the package back to its old name, the problem returns. Importing a new copy of the .dtsx file into the same (broken) project did not fix the problem. [Referring to answer by #Joe]
Here is the only solution that always works for me:
Create a new Visual Studio (or SSDT) solution.
At the new project dialogue, choose "Integration Services Import Project Wizard"
A wizard starts up [hit next if at optional "Wizard Introduction"]
At "Select Source" page choose "Integration Services Catalog"
Browse to server and the project deployment you need to fix
This works, but if your deployed SSIS package(s) was not up to date you need to continue with these two actions:
Delete the package(s) in the new (fixed) solution that are old.
Import the newer package(s) via "Add Existing Package" from the problematic solution
I suspect this happens due to a problem in the .database or .dtproj file.
I have just encountered this; solution opens but all blank and no sub folders or files in the Solution Explorer. Tried the above suggestions, but no luck. Right clicked on the solution name and selected 'Reload Project' and all good.
Hope this helps someone.
In the Solution Explorer right click on the .dtsx package file and then click on View Designer.
I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed, even when I've made no changes to the project!
I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and is creating clutter in source control.
Is it possible to stop these changes from occurring, or get rid of the .dbmdl file whatsoever?
If you delete the .dbml file, it is rebuilt without errors or warnings, so I think it's just a cache file for references, intellisense, etc. I'm going to exclude it from source control.
I believe Visual Studio serializes the dbmdl file every time the project is opened. The only possible work around would be to keep the project open.
See related question here. The .dbmdl file is unique per user (and some kind of cache, as said above) and so the right solution is indeed to exclude it from source control.
I'm writing a tool to automate documentation and deployment of code for our website and I came across an anomaly while testing and it throws into doubt my understanding of changesets.
What I'm seeing is a changeset referencing files that aren't actually part of the solution (although at one point they were).
As best as I can determine this is the series of events (all but the last step happened before I joined the company and so this is all deduced from source control history) :
A folder is added to a project containing around a dozen txt files which serve as templates for e-mails and these are checked in to TFS
2 weeks later four of the txt files are removed from the project but not physically deleted
2 years later a developer had a task to update e-mail templates and changed all the txt files in the folder including the four that aren't "in" the project
Developer checks in his changes resulting in Changeset X
When I look at Changeset X and its list of changes it includes an "edit" to each of the txt files including the four removed files. I've checked the CSPROJ file and there is definitely no reference to the removed files in there at the point the changeset was made.
When my code iterates through all the changes in the changeset it tries to marry up the changed file to the project it belongs to in order to identify what file(s) need to be deployed as a result of the change - ie if its .html or .jpg then it just gets copied but if its source code then I need to deploy the associated binary that gets compiled from the file). So when it finds these files and tries to find a project that they belong to it fails.
Should the changeset reference these removed files or is it a bug in TFS? Or could it be something that happened when the code was migrated from TFS 2008 to TFS 2012 at some time in the 2 years before the two changesets? If its not a bug then in what circumstances would you expect TFS to track changes to files not in the project?
I've tried to replicate it by setting up a totally new project and adding it to source control and then adding, removing and editing an associated text file but I can't get it to behave in the same way.
TFS is right. Visual Studio Solutions are a nice interface for visually managing a subset of files in Version Control. It is common to have more than one solution and change files in multiple places, but still is a single logical change that I want to record as a single changeset.
I am developing a WinForms C# projet within my company.
We use Visual Studio 2010 and Team Foundation Server 2010 to manage code versions.
I want to restore a version of a Form.
Let's call the Form MyForm.
MyForm is made up of three files :
MyForm.cs which contains the code behind.
MyForm.Designer.cs which contains code automatically generated by VS2010 when designing the Form.
MyForm.resx.
Here is a simplified historic of change sets :
Change set number : 1587. Files archived :
MyForm.Designer.cs. A TextBox control has been added. Let's call the TextBox control txtMyBox.
MyForm.cs. txtMyBox is used in the code behind.
Change set number : 1390. Files archived :
MyForm.cs
Change set number : 1299. Files archived :
MyForm.cs
MyForm.Designer.cs
...
Change set number : 986. Files archived :
MyForm.cs
MyForm.Designer.cs
MyForm.resx
Here is the procedure I have followed :
Right-clicking the MyForm.cs file in the solution explorer.
Clicking the "Getting a specific version" option in the contextual menu.
Selecting the change set number 1390 and then clicking the "Getting" button.
Then I have tried to open MyForm in the designer but an error has been displayed.
The error message has told me that the extraction has been cancelled.
What did I do wrong ?
you have the old version of MyForm.cs (no textBox) but the latest version of MyForm.Designer.cs (with TextBox).
You can do a couple of things
Do a get specific version on the folder containing both files, this will revert all files to the version available when changeset 1390 was checked in. (you might not want to do this if you have other files that you need to have the latest version of)
Do a get specific version on MyForm.cs at 1390 and a get specific version on MyForm.Designer.cs at 1299
This should ensure that both files are in sync with one another and fix the problem.
This is kind of old but I had this same issue recently and this is my fix. VS2012 and TFS2012
Delete the local workspace version and then get latest. Thats it.
I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed, even when I've made no changes to the project!
I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and is creating clutter in source control.
Is it possible to stop these changes from occurring, or get rid of the .dbmdl file whatsoever?
If you delete the .dbml file, it is rebuilt without errors or warnings, so I think it's just a cache file for references, intellisense, etc. I'm going to exclude it from source control.
I believe Visual Studio serializes the dbmdl file every time the project is opened. The only possible work around would be to keep the project open.
See related question here. The .dbmdl file is unique per user (and some kind of cache, as said above) and so the right solution is indeed to exclude it from source control.