Visual Studio 2019 (.sln) support?

Yes please. We're also eager to move forward with VS 2019. 

Same here, has already caused problems for us with .net core products targeting 2.2 that are building via msbuild, as without msbuild 16 they won't build and there is no way of selecting 2019 for msbuild type tasks. Seems a bit of an oversight to require a new release of tc for each new msbuild version? Doing it via a plugin we can update would make more sense. Tempted to swap them all to command tasks so this won't be a problem going forward.

Hi all. Support has already been checked and built in. It will be added in the second EAP for 2019.1: https://youtrack.jetbrains.com/issue/TW-59392

@Steven: May I ask you to open a specific request in our tracker to request that? Please consider that there might be breaking changes on MS' side that we might need to check upon every release, but for new releases where there are no such changes this would make sense to have. Maybe it would make sense to add a note on non-tested versions that they might misbehave.

HI Denis,

Could you let us know when the EAP with VS 2019 support will become an official release?

Thanks in advance!

Junhe

Hi Junhe,

It should be available already: https://blog.jetbrains.com/teamcity/2019/03/teamcity-2019-1-eap2-is-available/

Hi Denis,

Thanks for your prompt response ... I didn't ask the question right.

Do you know when the features of eap2 be integrated into a supported release (say perhaps a release after 2018.2.4)?

Thanks a lot,

Junhe

@Steven if you do make the YouTrack request, could you please post the link in this thread? That would be a huge improvement over the current situation.

Right now we have a really uncomfortable mishmash of commandline tasks, VS runners, and MSBuild runners. It would be really nice if we could standardize on something but we've found it very difficult to get TC to behave consistently with the newer technologies.

It's not as though the project system has changed a lot since the VS 2019 previews were released and the R# team seemed to manage 2019 support almost at day 1 for the RCs. It wasn't perfect but at least it tried. MS gives plenty of lead-up time for new VS releases and it's disappointing when the CI tools can't keep up with it.

@Junhe, ah gotcha. As it's a new feature, and not a bug fix, it's planned for 2019.1, and will likely not be backported into 2018.2.x

If you'd need to have it for 2018.2.5, please request it on the issue tracker on the issue mentioned above. I can't say it will be backported, as I'm not sure how difficult that would be, but posting it there is your best chance for it.

Hi Denis,

Thanks!

Junhe

Any updates on when 2019.1 will be ready so we can use VS2019?

There are several security vulnerability fixes between point releases .Net Core 2.2.107 and 2.2.5 which we do not want to wait too long to get installed.

VS2017 is not compatible with anything above .Net Core 2.2.107.

Thanks.

Hi Gary,

We expect to release 2019.1 by the end of next week. We are working on the last few bugfixes and verification by the QA team, so we would like that date to stick, but as usual, please keep in mind something might be picked up on the last minute that needs to delay the release a bit further.

Fantastic news! Thanks much.

A quick follow-up, that I forgot to mention. If you really need to build using the newer versions before the release, while you would lose some of the integrations, you might want to use a command line step to run the build commands as scripts instead of dotnet. The command line used to run the build is usually displayed in the build log so you can just use it as your own script. Might be useful for somebody checking this before the release.

Good suggestion. I think we can wait a week or two, but if we have to we will use this approach. Thanks.

I have version of TC 

TeamCity Enterprise 2018.1.5 (build 58744)

Does this mean I am unable to build VS2019 projects ?

I cannot update TC at this time but need to get projects build using MS build tools ver 16 aka VS2019 ? 

We have a TeamCity server running 2019.1.3 with a full version of VS2017 Enterprise installed. This morning I installed "Build tools for VS2019", shortly after all our .Net builds started failing, they build with the following build step. To fix it we had to uninstall "Build tools for VS2019". Should I open a new support issue for this?

note for anyone finding this: TeamCity Agent 2019.1.4 (docker image) __STILL__ does not find the MSBuildTools15.0_x64_Path or MSBuildTools15.0_x86_Path even if you have them installed.

Hi Andrew, Brian, and Jeff,

@Andrew: I'm afraid that's the case, at least using the embedded tools. You can always use a command line runner and run the commands manually, otherwise you will need to upgrade.

@Brian: First of all, please make sure that you restart the build agents after installing the tools for them to be detected. If you kept the MS Build Tools 2017 installed, kept the setting and are facing errors after installing 2019 and restarting the agent, please collect the teamcity-agent.log and the full build log for the failing build and forward those to us using the Submit a request button on top of this page.

@Jeff: The 15.0 parameters have been working since MSBT2017, which is a couple years now, so saying that it "still" does not find the tools is incorrect for the general case. If the docker image you are using is not detecting the MSBT 2017 but they are installed, send us the teamcity-agent.log including the startup process of the agent for us to review using the Submit a request button on top of this page, and indicate where your tools are installed and which image you are using.

Thanks for replying Denis.

Maybe first I should ask - is the expected behaviour of the 2019.1.5-windowsservercore-1809 (or 2019.1.5-windowsservercore-1803) teamcity-agent docker images that I should be able to build with Visual Studio 2017 & 2019 support? (including Build Rools v15 & v16)?

Hi Jeff,

the official images should carry the MS Build tools and be able to work, yes. They didn't in the past because of Microsoft licensing issues but they eventually changed their policy allowing us to distribute them. If they're not working in your case, as mentioned, please provide the data requested as we need to look deeper into them.

Denis - I'm pretty sure that if you just run the stock TeamCity Agent Docker agent (not minimal) for Windows 2019 (1803 or 1809) you won't have it detect MSBuild Tools for VS 2015, 2017 & 2019 (tools versions 14, 15, 16).

Hi Jeff,

As you can see, it works on our tests. Running builds for it using VS 2019/MSTools 2019 works as well. So please, if you are having trouble with it, as mentioned, send us the requested logs.

Denis,

You are showing exactly what I see - that build Tools v4 and v16 are detected, but not v14 and v15. 

If you:

1. choose Build Runner of 'MSBuild'
2. MSBuild version: Microsoft Build Tools 2017 (or Microsoft Build Tools 2015)
3. MSBuild Tools version: 15.0 or 14.0 (for build tools v2017 or 2015 respectively)

Your project configuration will not be compatible with the agent.

I realize you may say "the docker image does not have those build tools installed"

(a) why not?

(b) when I install them, the TeamCity agent does not detect them

If i manually setup the MSBuildTools15.0_* agent properties, then it will detect them, but that presupposes I extend the docker image and manage to get the tools installed and manually configure the resulting image. I'm a docker newbie so maybe that seems trivial, but no on eon my team nor I are experienced in docker - but love TeamCity and just want to have the easiest way possible to get the server and agents running,

Note: there was a CloudFormation stack I used (from Jetbrains I think) which was great - now I'm trying to push it further to get all the different MS build types going for our various projects.

Hi Jeff,

thanks for coming back, I got confused by the fact that this thread was about VS 2019 and those variables had been there since roughly 2017 (when microsoft changed policies), hadn't noticed that they were phased out with the tools version 16. I'm gathering the info from the maintainers of the images as I'm not sure whether this is fully intentional or an oversight and will report back as I get anything from them.

About installing on your own, tools are detected upon agent startup, as I answered to Brian. If you install them manually, the agent needs to be restarted. With docker images this is tricky, because docker will typically detect the process going down and shut down the image. The solution is to create a custom image or use custom parameters. Of course, there is a last resort possibility of using the command line runner and run the builds with custom scripts.

As a general rule, we provide images with a base set of tools that we expect cover most scenarios, but it's understood and expected that we can't cover all of them. For that case, the recommended approach is creating a new image (based on ours if required) that contains the required tools.

Thanks Denis.

I have created a custom Docker image to install some other tools (like AWS CLI, etc.) so at least I've gone that far - but the MS tools don't seem to like being installed in the Docker build for some reason. Even once I get some on there, you get that reboot issue you mentioned.

It would be super helpful to be able to maintain / edit the agent config files on the TeamCity server so I could centrally update and control additional settings that get sent to the Agents when they register vs doing it inside the docker image, but I don't know enough about the agent registration process to know if that suggestion has a host of issues for other reasons.

Hi Jeff,

I created this issue in our tracker to follow the progress of the issue: https://youtrack.jetbrains.com/issue/TW-63336

Please watch and vote for it to stay informed of its progress.