I'm struggling to get Azure Devops Server 2019 (on prem) to build a complicated project setup of mine.
I have multiple solutions that build various BizTalk apps. Some of these solutions references some of the projects in other solutions/repos. This works fine in Visual Studio (providing everybody names their repos as the default, which they do).
To automate this build, I've created a multi-stage build pipeline that builds each solution in order.
Whilst solution 1 will build successfully, when it comes to solution 2, the msbuild tasks will not reference the outputs for the projects that have been included as a project reference in the solution.
This seems to be because these referenced projects aren't marked for build - because they wouldn't be able to build themselves without them in turn referencing their other projects in the main solutions etc.
Bundling everything into one big super solution file is not feasible.
I'm wanting msbuild to /reference the projects that have already been built in the previous step, as per being included as project references. But msbuild is a complicated beast and I cannot figure out a way of achieving this.
Is what I'm trying to achieve even possible? Can anybody point me in the right direction?
TFS / msbuild, building project references
This is a known issue about project reference in different Repos, but unfortunately it doesn't have a best answer. Because the best solution is always to have a single repository.
Git thinks of files as the content of the whole repository, not as a collection of files. Therefore this is quite hard to do. As workaround, you can consider to use Git Submodules or Git Subtree:
Check the details info from here:
Git and Visual Studio project references
Besides, the solution we are using now is to put the shared code in the NuGet package. Then, you can use the package from any repository, and you don't have to perform any unstable git settings and keep access control as they should be.
Hope this helps.
It seems that msbuild was changed to only reference project references, and that you can revert that to reference all references by setting the property OnlyReferenceAndBuildProjectsEnabledInSolutionConfiguration to true when running msbuild.
Source: https://stackoverflow.com/a/25144169
Have confirmed this works.
I've finally revisited this and done some more experimentation.
The only way, that I can see, to get TFS/msbuild to /reference other projects outputs is to mark them in the solution build configuration to build.
Now if you do this in Visual Studio and try and build a solution that has projects from another solution then the build will fail if the previous solution hasn't been fully built yet (as the other chained dependencies won't have been built). This makes sense.
But with TFS/msbuild, the build will succeed. From what I can tell there is some magic going on that ensures the dependencies across all solutions are somehow resolved. This might be luck, it might be specific behaviour (it's working for me so far).
The problem of course is that it's incompatible with Visual Studio. So I have an extra "Build" definition setup in each Solution file that has all the projects set to build.
This seems the easiest way to manage lots of interrelated solutions without having one big one.
We had performed the migration of our whole repository from TFS to VSTS using OpsHub. It seemed to go ok except for some projects that it just couldn't handle. Everything looked ok, until developers were going into projects and find all the files that had been deleted from the projects. This has left all the projects and folders a mess. If you look in the history of those projects you can see the actual deletes in the changesets reflected by the file being displayed with a strike-through going over name. But looking in the folders the files are there. If this was an existing issue, was it part of some disclaimer that we missed?
Is there any way to cause those deletes to occur? We don't want to have to migrate everything again because it took weeks to get everything migrated before. I just need to find out if there are any other options.
Consistently getting a checkin error via VS2013 for a MVC project. Have been spending quite some time but still dont get whats happening.
The project is cleaned. Checked that Application Experience is set to automatic. I am running on Windows 7
Any help ?
There is a file in your solution that does not exist on disk. Maybe it was deleted manually. If you know the file you can go looking for where it is referenced in your project hierarchy. It should be listed with a yellow triangle.
Either remove it or replace it.
If you don't have a local copy but it is still on the server you can find it in the Sourfe Explorer and do a Get Specific | Latest to recreate it.
When I originally installed VS Ultimate 2013 everything was fine but for the last month or so it's been a dog.
The source control explore in my Visual Studio 2013 install is very slow. Just clicking on a node and the act of displaying the node contents takes 20+ seconds.
Everyone else on the team is ok so it's not the TFS server it's just my install.
I assumed it was some addin I'd installed into VS so disabled them but no luck.
Any ideas?
Having tried all suggestions, unloaded all add ons, tried to reinstall VS, removed all extra workspaces etc. the answer to my problem was to unmap my workspace and then remap it.
Problem solved. Not got a clue what the underlying fault was.
In my case, the only way to get rid of the lag was to change my workspace location from "local" to server. You can do this under the advanced options for your workspace.
The 'full blast' solution that worked for me was;
remove workspace
delete all source code
rebuild the workspace
rebuild solution
Only takes a few minutes more than just rebuilding the workspace (see #DaveF's answer) but gave me a bit more confidence that everything hangs together.
Had this happen to me a few times now, so there are some things I'd like to add to the accepted answer.
I work in a place where we have a lot of VS solutions with a lot of files in them. Microsoft's guidelines suggest that you shouldn't be using a local workspace if its going to have more than 100,000 items in it. So you could prevent this problem entirely by:
Not using local workspaces
Making sure never to map enough folders into a single workspace that it gets over 100,000 files associated with it.
Periodically declaring "TFS bankruptcy" and unmapping everything.
For me, the drawback of having to use strict locking and not having offline access makes #1 unacceptable. I'm going to try harder to do #2, but honestly #3 is what I've been living by.
Its kind of like early Windows, where every year or so you had to just reinstall the OS to remove all the accumulated cruft.
Cleaning local folders helped: See 'Team Explorer - Pending Changes', under 'Excluded Changes' it said: 'Detected: 50000 add(s)'. Click it to see path to folders.
This make me crazy too for over six months until I found this instruction. Now, my VSO is fling. Note: this information I copy from somebody. Would like to give them credit but I cannot remember how did I find this.
You can fix this problem of TFS by editing registry.
Navigate to key
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl\Proxy
and then change value of URL to any dummy website like 'www.abcdummy.com'
Restart VS after editing registry key value.
I had the same problem, it kept me busy for a week or so, but after investigating my complete setup i found the following:
Within my ASP.NET application, i had an image directory and an image cache directory, with lots of images in them. (+200.000). Both were not included in my VS project, but still Visual Studio / TFS tripped over this.
First i found, that when checking in some files (which took over 10 minutes when the problem existed), in 'Team Explorer - Pending Changes', under 'Excluded Changes' it said: 'Detected: 50000 add(s)'.
Trying to get rid of this the 'normal way', by opening that 'Promote Candidate Changes' window and setting these files to be ignored, still didn't do much.
But after moving those image directories to some other location, outside my project, all problems disappeared.
Of course i had to add those moved directories as virtual directories to still see my images.
I cleaned my workspace of unnecessary projects and it ran better. I think vh_click is on to something with the 50,000 ads thing. TFS keeps track of all your edits and over time with tons of projects, undos, and craziness you could amasse a large set of which TFS has to chug. Get out the Clorox, the Comet or whatever else you clean with and dump some junk or move it to some archive folder or backup drive.
Cleaning up the Workspace was the solution for me, when opening visual studio 2015 the Source Control Window will remain in a Loading phase, I had 2 workspaces name and name_1 and I removed both.
No need to delete the entire folder, though , keep in mind that if you do delete the workspace and have the files, you will need to force the get latest to be on the safe side
Getting Latest was soooooo slow. I was using a Colleagues PC and had deleted his Workspace.
After an hour waiting to get latest I got an error and realised my User Account didn't have Full Control on the folder, giving Write Access made Get Latest run x1000 faster:
Just to throw another solution in the mix! I had the same problem which seemed to be caused by several layers of working folders configured in my workspace (some overlapping ones too).
The issue was resolved by going to Manage Workspaces, then Edit and then removing the additional folder bindings.
in short "Run it as an administrator".
No one of those solution does work at all, I even search on this link:
Why is Visual Studio 2013 very slow?
In vain, just do this ONE simple step:
Go to your visual studio path, usually installed on this path:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE namely the file "devenv.exe" , then right click on it, click "Run an administrator" ===> then open your visual studio project.
So, you can just send a shortcut of "devenv.exe" to the desktop to easily run it as an administrator each time.
Have ^_^ Fun
You can keep workspace on local and change your workspace to this. I did that and my TFS speed was great :
1- Remove all mapped folders in workspace "Edit":
2- Change workspace folder to parent all of mapped folders:
I hope it is useful for you.
I am using Visual Studio Online. I have projects which have common code that I use across a number of different solutions in different TFS projects and I also have some files which are linked from other TFS projects in some of them. In order to be able to access them all, I've changed the Workspace config so that I have just mapped $/ to a particular folder.
The problem is that I just checked in a change in one project and noticed that it also checked in a change in a completely unrelated one that wasn't part of the solution at all! How can I configure things to be able to access everything that I need to without cross-checking-in files from unrelated projects (and without having to manually exclude/include files in every check in)!?
EDIT: I've noticed that this doesn't seem to have happened again on my last couple of check ins when I also had items from other projects checked out. Wondering what caused it.
You should look at a NuGet solution for this. If you are using VSO you can use the new MyGet integration with an automated build process. If you create an automated build for the shared project output that is packaged in a NuGet package you can create a NuGet repository ion MyGet to provide it to your other solutions.
Once you have that, if you then change the shared code and check in, the build and package will kick off and deploy your new version of the package. Your other solutions will then prompt you to update automatically. You don't even need to check in the dependent assemblies as you can use NuGet Package Restore to make sure your local and build server get the right versions.
It sounds like a lot of work but once you get up to speed it only takes a few hours of investment to configure for anything you want to share or deploy in this way.
In the Pending Changes section of Team Explorer, in the Included Changes section there is a drop down. If it's set to "Show All" you'll see changes pending for all your solutions. If it's set to "Show Solution Changes" you'll just see changes pending for the current solution. (My guess is that it was set to "Show All" when you checked in your changes and that's why you got changes from other solutions checked in.)