Closed mikeesouth closed 7 years ago
If you are using hosted agent - then the tooling there works only with project.json files. We will be working on adding support for csproj based .Net Core projects to hosted images. However, if you use your own agent and install the tools supporting csproj files - the task would work.
@sachinma, I don't fully understand, when using VS2017RC the project.json files are deprecated when converting the solution, so we can't build VS2017 projects now at all on a hosted build agent?
You are right about your understanding of the current state. VS2017 RC based .Net core projects cannot be compiled on the hosted build agent right now. As I mentioned, we are working to add that capability. In the meantime, as a workaround you can use a private build agent which has the right version of .net core tools and then use the task.
Thanks!
I was hoping there would be some hackety-hackety way we could still build it on the hosted build agent, but I'll end my quest here :)
hi @sachinma any ETA for building core on vsts (hosted build)? will it be available when vs2017 RTMs early march?
It would be great if VSTS kept up more closely with .net core... right now, we re a bit stuck without any real timeline.
Yes. When it RTMs, it will be on our image. We've been keeping up with it. The issue is we have one hosted image. That image is at max size (128GB) due to all the versions of VS and other tools. So for that reason, we will have to pull older versions and replace with 2017. In parallel we have multi image support in the pipeline to address the main problem. With that, we'll have an image per era of VS and even be able to release preview images before RTM of next VS versions.
In the meantime, private agents are an option and private agents work with VSTS.
Why is this marked as closed though? It's clearly not fixed yet.
this is really holding us back from doing any .net core projects at the moment. hope it will be fixed as soon as RTM releases next week! private agents are no solution, as we use this whole vsts as a service to stay out of that nightmare.
VS 2017 released and still not working
Not working for me either. Is the .Net Core (Preview) build step still the right one to use or should we be using the MSBuild step?
Is there a plan when the new (and now Released) Csproj Format Support will be there for Hosted Agents? It would be helpfull to know, because when someone would say Q3 2017 then (for me) it would make sence to spent time to build a Strategy for Automating the Setup of Build Agents and just forget about the Hosted Agents. (And when i would have to care about the Agents why then not using directly an On-Promise Installation...)
Not working for me, either... sigh... Brand new core 1.1 web app project created in VS 2017, new VSO project collection. New build definition from the .NET Core (PREVIEW) template.. Bombs. Says that .csproj file not recognized. All rainbows and lollipops in the VS launch demos today, but in real life.. sigh..
I am having the same problem
2017-03-08T00:31:16.8747494Z ##[section]Starting: Restore 2017-03-08T00:31:16.9217495Z ============================================================================== 2017-03-08T00:31:16.9217495Z Task : .NET Core (PREVIEW) 2017-03-08T00:31:16.9217495Z Description : Build, test and publish using dotnet core command-line. 2017-03-08T00:31:16.9217495Z Version : 0.4.1 2017-03-08T00:31:16.9217495Z Author : Microsoft Corporation 2017-03-08T00:31:16.9217495Z Help : More Information 2017-03-08T00:31:16.9217495Z ============================================================================== 2017-03-08T00:31:18.5392559Z [command]C:\Program Files\dotnet\dotnet.exe restore D:\a\1\s\LifestyleFlexibility\LifestyleFlexibility.csproj 2017-03-08T00:32:41.2362472Z 2017-03-08T00:32:41.2372463Z Welcome to .NET Core! 2017-03-08T00:32:41.2422475Z --------------------- 2017-03-08T00:32:41.2422475Z Learn more about .NET Core @ https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs. 2017-03-08T00:32:41.2422475Z Telemetry 2017-03-08T00:32:41.2432475Z -------------- 2017-03-08T00:32:41.2432475Z The .NET Core tools collect usage data in order to improve your experience. The data is anonymous and does not include commandline arguments. The data is collected by Microsoft and shared with the community. 2017-03-08T00:32:41.2432475Z You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell. 2017-03-08T00:32:41.2432475Z You can read more about .NET Core tools telemetry @ https://aka.ms/dotnet-cli-telemetry. 2017-03-08T00:32:41.2432475Z Configuring... 2017-03-08T00:32:41.2432475Z ------------------- 2017-03-08T00:32:41.2432475Z A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once. 2017-03-08T00:32:41.2445274Z error: Invalid input 'D:\a\1\s\test\test.csproj'. The file type was not recognized. 2017-03-08T00:32:41.2542476Z ##[error]Dotnet command failed with non-zero exit code: 1. 2017-03-08T00:32:41.2582479Z ##[section]Finishing: Restore
This is endlessly frustrating... the end to end tooling still isn't there. Every time you think we're good to start using Core in a meaningful way, something else isn't "done."
That is clearly not out yet.
still not working :(
for those who are blocked, i created a task group that downloads the latest tools and unzip in my sources directory. i then use command lines with what i downloaded. works fine if you don't mind downloading and unpacking everytime.
alternatively, you may use the dotnet install script (there is a version for linux and windows). havent tried that one...
Why is this closed? It is currently impossible to build csproj based .NET Core projects on VSO.
Is there an ETA at least? Every reference I can find says "by RTM".
Some people rely on VSO for dev-ops and production...
+1
I agree with with dcarl.. Why is this closed???? I spent all day yesterday trying to get a VS 2017 .csproj to build on VSO. Tried MSbuild, Visual Studio 2017 build steps.. no success. In addition, another unit test project that was still project.json based starting failing on VSO the minute I upped it to .NET Core App 1.1.1. Had to rollback to 1.1.0. Sigh... I am really getting tired of the constant frustration of "RTM" products that are released which are clearly not ready. I am the lead developer at my company giving VS 2017 a test run. I can not recommend that our company upgrade to VS 2017 until at least SP 1 comes out. Sound familiar from the old days?
I'll reopen till your scenario works.
There's two separate things - the tasks (this repo) and the hosted pool image which doesn't have 2017 and new dotnet cli tooling installed on it (not covered in this repo).
Good news is that image is rolling out now ( we were waiting for final build which we have).
You will see another Queue for your def to target (VS2017).
Other piece of good news for the future we will have multi image support on hosted. That will allow us to have separate images with early previews of tooling, images for different toolsets like java etc... Smaller images that make us more nimble rolling out things (our monolithic image was 128GB and regen would reset testing on every dev scenario).
Hopefully that explains it a bit better.
@dcarl1 @srpeterson @moattarwork - we will wait for your ack and feedback on the overall scenario to close.
Sorry for you issues here.
Thank you for your quick response. I will give it another shot later on today and provide feedback
@bryanmacfarlane Good day. I understand the image is quite big, and may take some time to roll out. As of right now, I do not see that new Queue option. Is there an expected ETA for this to be completed?
@bryanmacfarlane Thank you. With newly released dev tools Github is the best (and often only) resource to get information about what is working within the tool chain. Having the ticket open until it works at least prevents people from wasting time trying to get it to work.
I don't see any difference too. That would be ideal if you add a quick steps as well. Currently you have two templates for build in VSO both in preview which one is ASP.net Core and the other one is ASP.net and the latter has support for solution build but it can't find and compatible agent.
Hi. I just fired off another .NET Core (Preview) build on my VS 2017 .csproj web app on VSO. Sorry to say, but it is still failing. It fails on the "Restore" step before it actually builds:
rror: Invalid input 'D:\a\1\s\DocumentDb.Poc.Api\DocumentDb.Poc.Api.csproj'. The file type was not recognized. Dotnet command failed with non-zero exit code: 1. C:\Program Files\dotnet\dotnet.exe restore D:\a\1\s\DocumentDb.Poc.Tests\DocumentDb.Poc.Tests.csproj error: Invalid input 'D:\a\1\s\DocumentDb.Poc.Tests\DocumentDb.Poc.Tests.csproj'. The file type was not recognized. Dotnet command failed with non-zero exit code: 1.
Any ETA on when the new image might be up and running?
Are we talking hours, days, weeks, .. here?
This is hardly a surprise, this change to .NET Core has been coming for many, many months, and there has been the SDK tooling that supports .csproj and project.json availble for almost as long
It should go out with our current (114) sprints rollout. Sprints take 1 - 2 weeks to roll through scale units.
Per above, you will know you have it when you see a VS2017 queue. The hosted pool queue image does not have VS2017.
@benc-uk - correct this isn't a surprise. We've been working with .net core since it's inception. Our agent is even built with .net core and we've followed it's tooling closely (we recently changed our build from project.json to .csproj). The issue is what I outlined above - our single image only contains released products primarily because there is often SxS issues of pre-released software impacting other versions and currently stable builds. We are working on separate image support (realized as separate queues) so going forward we hope to have images with pre-released versions available in our hosted pool as they become available to users.
We realize this as a limitation and problem in our hosted pool which is why we're working on separate queue and image support in our hosted pool. We had originally hoped to make VS2017 available on the single image but it was too large and we couldn't remove VS2010 (to make room) without breaking some folks builds. So the work was pinned up behind the release, the new image and a subset of the new image support (enough to create another queue) on the VSTS build side.
Hope that clarifies.
The workaround is to create a private agent on an azure VM.
What does it mean "see a VS2017 queue?" You guys are talking about pools, images and queues as if we all know and understand the underlying infrastructure of VSTS. I understand build definitions and steps within them.
@jeffputz I think it means agent queues, we should see another one for VS 2017 appearing soon here:
@bryanmacfarlane please correct me if I'm wrong
For those in a non-production testing environment, I found creating a private agent on my local PC does the trick. It seems odd to push code up to VSTS, only for it to push it back to perform the build and tasks, but regardless, it allows continued movement on testing out the new features using VSTS.
@mbowman8 I originally moved to VSTS because I don't want to manage local infrastructure.
+1 - any updates?
Since it sounds like this is a week or two away from roll out I've spun up a private build agent on Azure. The process is pretty simple, I (roughly) documented it here:
Pretty simple unless, as others have pointed out, you're in this in the first place to get out of the business of maintaining your own infrastructure.
@jeffputz Yes, but it is a temporary work around while the images roll out.
If anyone is using Docker I've created an VSTS build agent image with the latest .NET Core SDK installed. I've used this with VSTS to successfully build & publish .csproj based projects. https://hub.docker.com/r/bencuk/vsts-agent/
You can download the latest version of the .net core SDK on the hosted agent https://social.msdn.microsoft.com/Forums/vstudio/en-US/f05d8aea-e917-4711-b7ef-93ed5ade84d0/csproj-the-file-type-was-not-recognized?forum=TFService&prof=required#0f1b77f4-ab11-4b66-aba3-4ebe58c0b3ca
@sachinma Could you provide an update? Clearly still not working at this point. I mean host does not build VS2017 with asp.net core issue.
Thanks
@sachinma As already pointed out, a current workaround is to install it as part of the build (it only takes about 3 minutes). Just copy this PowerShell script into your repository and call it as follows in a PowerShell build step (note that the installation and build somehow have to be in the same build step) $currentPath = split-path $SCRIPT:MyInvocation.MyCommand.Path -parent # where this script and the installer script lives cd $currentPath .\dotnet-install.ps1 cd "InsertSourceDirectoryHere" dotnet restore dotnet build
the above workaround (while not ideal) seems to work just fine
I followed instructions provided by @fred2u (https://social.msdn.microsoft.com/Forums/vstudio/en-US/f05d8aea-e917-4711-b7ef-93ed5ade84d0/csproj-the-file-type-was-not-recognized?forum=TFService&prof=required#0f1b77f4-ab11-4b66-aba3-4ebe58c0b3ca). It worked well and quicker than I had expected.
@koenmetsu thanks for the updates.
I see that you can now choose Hosted VS2017 in Edit / General / Default agent queue
.
Seems to work great :+1:
@hallatore I can't find this, can you share a screenshot of where it is please?
@aloneguid I think it's rolling out atm. Not sure it's available to everyone yet.
The VS2017 agent queue has just appeared in my account, and my .NET Core .csproj builds are working fine with it. Thanks guys
@hallatore ah thank you, probably still rolling out, I don't have it:
Hi,
I'm using ASP.NET Core with the latest dotnet CLI tools (
.NET Command Line Tools (1.0.0-preview4-004233)
) that uses .csproj files and no longer the project.json file.The
dotnet
command uses msbuild internally if I understand it correctly but the VSTS Tasks marked with "Restore/Build/Publish .NET Core (Preview)" does not work. I get this error:error: Invalid input 'C:/a/1/s/server/server.csproj'. The file type was not recognized.
Maybe I can use the MSBuild tasks?
According to this link, the hosted pool should support .NET Core 1.1 and I would assume the latest dotnet CLI tools as well?
The full log for
.NET Core (Preview) Restore
task: