Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1st class support for 'dotnet' tooling #1404

Open
IlyaFinkelshteyn opened this issue Mar 17, 2017 · 37 comments

Comments

Projects
None yet
@IlyaFinkelshteyn
Copy link
Member

commented Mar 17, 2017

AppVeyor support classic .NET projects out of the box. However new .NET Core and ASP.NET Core projects require some scripting to build, package, test and publish on AppVeyor.

For now settings like 'Package Web Applications for Web Deploy', 'Package NuGet projects' or tests auto-detection are misleading for .NET/ASP.NET Core projects

Main issues (to be continued)

  • detect nuget projects and run dotnet pack (previously used existence of .nuspec files to detect which is not the case anymore)
  • detect test projects and run dotnet test
  • detect ASP.NET Core application and run dotnet publish

@IlyaFinkelshteyn IlyaFinkelshteyn changed the title 1st class support for `dotnet` tooling 1st class support for 'dotnet' tooling Mar 17, 2017

@FeodorFitsner

This comment has been minimized.

Copy link
Member

commented Mar 18, 2017

Discussion about dealing with package version: #1179 (comment)

@FeodorFitsner

This comment has been minimized.

Copy link
Member

commented Mar 20, 2017

Analyze global.json in the root of solution. If it doesn't exist then consider solution as the one based on SDK 1.0.0 with .csproj. .xproj-based solutions relying on "preview" SDKs won't be supported by AppVeyor "automatic" mode.

@FeodorFitsner

This comment has been minimized.

Copy link
Member

commented Mar 21, 2017

Providing nuspec to dotnet pack command: #1404

@HarelM

This comment has been minimized.

Copy link

commented Apr 13, 2017

latest msbuild for .net core project support the /t:pack, this is another option:
msbuild /t:pack /p:Configuration=Release
See here:
https://docs.microsoft.com/en-us/nuget/guides/create-net-standard-packages-vs2017

@IlyaFinkelshteyn

This comment has been minimized.

Copy link
Member Author

commented May 1, 2017

We probably have to add an option to "Patch .csproj files for .NET Core projects" under AssemblyInfo patching section. Thus will make automatic nuget versioning for .NET Core projects more straightforward. More info: http://stackoverflow.com/questions/42138418/equivalent-to-assemblyinfo-in-dotnet-core-csproj

@jogibear9988

This comment has been minimized.

Copy link

commented May 21, 2017

Not only the AssemblyVersions, also the PackageVersion should be patchable

@jogibear9988

This comment has been minimized.

Copy link

commented May 28, 2017

Any News when this will work?

@IlyaFinkelshteyn

This comment has been minimized.

@IlyaFinkelshteyn

This comment has been minimized.

Copy link
Member Author

commented Jun 26, 2017

charvey added a commit to charvey/my-commute that referenced this issue Jul 3, 2017

WilkaH added a commit to int2017/Inspicio that referenced this issue Jul 11, 2017

Added an appveyor.yml file for CI
I've setup a CI build at https://ci.appveyor.com/project/Wilka/inspicio, but it needs a config file to build
.NET Core apps. I'm following the details at http://help.appveyor.com/discussions/questions/3577-compile-package-net-core

Once AppVeyor have appveyor/ci#1404 implemented, we might want to this a different way.

penartur added a commit to penartur/EternalArrowBackup that referenced this issue Jul 14, 2017

penartur added a commit to penartur/EternalArrowBackup that referenced this issue Jul 14, 2017

@penartur

This comment has been minimized.

Copy link

commented Jul 17, 2017

It seems that tests are correctly detected and invoked now.

However, something goes wrong with the environment on which tests are running; and the tests are failing with the following error:

System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

It also appears that the tests successful detection depends on the project naming; while I get this System.Runtime error for test project named ClassLibrary1.Tests, I get the similar error referring to xunit.execution.dotnet, Version=0.0.0.0 for test project called XUnitTestProject1 (https://ci.appveyor.com/project/penartur/minimalappveyordemo/build/1.0.6)

Example build report (with link to the example source code): https://ci.appveyor.com/project/penartur/minimalappveyordemo/build/1.0.9

Is there any workaround allowing one to run .NET Core-based tests on appveyor, besides manually invoking dotnet test for every single test project?

@HarelM

This comment has been minimized.

Copy link

commented Jul 17, 2017

I'm running code coverage on my tests so I need to do it manually anyway.
I have the following powershell script that does the job for me, you can script it to look for *Tests.dll if you need to, I have two test DLLs so I didn't feel the need...
https://github.com/IsraelHikingMap/Site/blob/master/AppVeyorBuild/PostBuildTests.ps1
Feel free to take the code and adopt it however you want, it also runs angular karma tests...

Z1ni added a commit to Z1ni/Z1Torrent that referenced this issue Jul 22, 2017

@IlyaFinkelshteyn

This comment has been minimized.

Copy link
Member Author

commented Aug 3, 2017

@bramborman

This comment has been minimized.

Copy link

commented Aug 3, 2017

@IlyaFinkelshteyn Great, I can finally remove my PowerShell patching and use this 👍

btw, there's a typo in the second article..
image

@IlyaFinkelshteyn

This comment has been minimized.

Copy link
Member Author

commented Aug 3, 2017

@bramborman Thanks! Fixed.

@lukespragg

This comment has been minimized.

Copy link

commented Aug 9, 2017

Is there a specific layout that the .csproj needs to be in? I'm using the VS2017 layout and building successfully with it, but AppVeyor it complains with:

X.csproj is not .NET Core .csproj file, patching skipped
No .NET Core .csproj files found

The .csproj starts with <Project Sdk="Microsoft.NET.Sdk"> and has the <Version> attribute set to 2.0.0.0 by default.

@IlyaFinkelshteyn

This comment has been minimized.

Copy link
Member Author

commented Aug 9, 2017

Logic to distinguish between "old" and "new" .csproj is taken mostly form here
@lukespragg could you please share .csproj file -- will see what we missed.

@lukespragg

This comment has been minimized.

Copy link

commented Aug 9, 2017

@IlyaFinkelshteyn, here ya go!

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <PackageId>Oxide.Core</PackageId>
    <Version>2.1.0.0</Version>
    <Authors>Oxide Team and Contributors</Authors>
    <Description>Core component for the Oxide modding framework</Description>
    <RepositoryUrl>https://github.com/OxideMore/Oxide.Core</RepositoryUrl>
    <PackageLicenseUrl>https://github.com/OxideMod/Oxide.Core/blob/develop/LICENSE.md</PackageLicenseUrl>
    <PackageProjectUrl>https://github.com/OxideMod/Oxide.Core</PackageProjectUrl>
    <PackageIconUrl>https://avatars1.githubusercontent.com/u/10712027?s=64</PackageIconUrl>
    <Copyright>Copyright (c) 2014-$([System.DateTime]::Now.Year) $(Authors)</Copyright>
    <PackageTags>gaming modding plugins unity unity3d</PackageTags>
    <TargetFrameworks>net461;net45;net40;net35</TargetFrameworks>
    <GeneratePackageOnBuild>True</GeneratePackageOnBuild>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="10.0.*" />
    <PackageReference Include="WebSocketSharpFork" Version="1.0.*" />
    <PackageReference Include="protobuf-net" Version="2.0.*" />
  </ItemGroup>

</Project>

I also noticed that AppVeyor won't automatically package builds (.nupkg) if <PackageId> is not explicitly set.

@IlyaFinkelshteyn

This comment has been minimized.

Copy link
Member Author

commented Aug 9, 2017

Sorry, silly bug #1710. Will fix it with the next build worker update. As a workaround pls use manual patching for now: https://stackoverflow.com/questions/44740502/how-to-use-dotnet-pack-with-appveyor

@lukespragg

This comment has been minimized.

Copy link

commented Aug 9, 2017

I am using a PowerShell script right now for the version replacement which works. Also, packaging works fine, just have to have that tag in there. I haven't actually looked at the contents of the .nupkg yet, but all frameworks specified in TargetFrameworks are building fine.

@IlyaFinkelshteyn

This comment has been minimized.

Copy link
Member Author

commented Aug 23, 2017

@lukespragg patching for your project should work with Visual Studio 2017 now.

@IlyaFinkelshteyn

This comment has been minimized.

Copy link
Member Author

commented Sep 6, 2017

@bramborman sure, please watch #1772

@lilith

This comment has been minimized.

Copy link

commented Sep 12, 2017

I have a .NET Standard project that I'm trying to test under both .NET Core and .NET Full.

  1. It would be great if 'nuget restore' was used for solutions with .NET Full projects (dotnet restore doesn't work for full, and nuget restore doesn't work for core).
@lilith

This comment has been minimized.

Copy link

commented Sep 12, 2017

When I let autodiscovery do its thing, this error happens if I have a .NET Core unit tests

%xunit20%\xunit.console.x86 "C:\projects\imageflow-dotnet\tests\Imageflow.Test\bin\Release\netcoreapp2.0\Imageflow.Test.dll" -appveyor
xUnit.net Console Runner (32-bit .NET 4.0.30319.42000)
System.InvalidOperationException: Unknown test framework: could not find xunit.dll (v1) or xunit.execution.*.dll (v2) in C:\projects\imageflow-dotnet\tests\Imageflow.Test\bin\Release\netcoreapp2.0``` 
@IlyaFinkelshteyn

This comment has been minimized.

Copy link
Member Author

commented Sep 12, 2017

@nathanaeljones Side-by-side .NET Core and classic .NET auto-detection and execution is what we working on now. Sorry it takes so long, hope to update this thread very soon. Regarding nuget/dotnet restore, please try to run msbuild /t:restore against solution (on Visual Studio 2017 image).

@lilith

This comment has been minimized.

Copy link

commented Sep 12, 2017

msbuild /t:restore on Visual Studio 2017 isn't working for me (packages aren't getting restored on .NET 4.6.1 project).
nuget restore tests/Imageflow.TestDotNetFull/Imageflow.TestDotNetFull.csproj -SolutionDirectory src works

@IlyaFinkelshteyn

This comment has been minimized.

Copy link
Member Author

commented Sep 12, 2017

@nathanaeljones maybe actual problem is that packages are set on project and not solution level (check this for example)?

yallie added a commit to yallie/MessageWire that referenced this issue Sep 16, 2017

yallie added a commit to yallie/MessageWire that referenced this issue Sep 16, 2017

tomasaschan pushed a commit to tomasaschan/RdbmsEventStore that referenced this issue Oct 3, 2017

Tomas Lycken
Move testing into custom script
Appveyor doesn't fully support XUnit on .NET Core yet; see appveyor/ci#1404

tomasaschan pushed a commit to tomasaschan/RdbmsEventStore that referenced this issue Oct 3, 2017

Tomas Lycken
Move testing into custom script
Appveyor doesn't fully support XUnit on .NET Core yet; see appveyor/ci#1404

tomasaschan pushed a commit to tomasaschan/RdbmsEventStore that referenced this issue Oct 3, 2017

Tomas Lycken
Move testing into custom script
Appveyor doesn't fully support XUnit on .NET Core yet; see appveyor/ci#1404

tomasaschan pushed a commit to tomasaschan/RdbmsEventStore that referenced this issue Oct 3, 2017

Tomas Lycken
Test suite (#14)
* Move longer ps1 script to separate files to fix syntax highlighting
* Add a first test and enable tests on Appveyor
* Build before packing, to ensure test projects are built
* Move testing into custom script

Appveyor doesn't fully support XUnit on .NET Core yet; see appveyor/ci#1404
@IlyaFinkelshteyn

This comment has been minimized.

Copy link
Member Author

commented Oct 24, 2017

After recent update AppVeyor is aware of .NET Core tests and can auto-detect and auto-run them. Please give it a try and let us know how it goes.

@TheBeardedLlama

This comment has been minimized.

Copy link

commented Oct 25, 2017

hey guys, is there an overall status summary on .net core support available somewhere?

it'd be good not to have to trawl through this issue to find what's ready and what's not

e.g. asp.net, publishing, etc.

@IlyaFinkelshteyn

This comment has been minimized.

Copy link
Member Author

commented Oct 25, 2017

@TheBeardedLlama right, scope of this issue is too wide. Right now we implemented the following:

  • patching for "new" .csproj file (doc)
  • automatic nuget packaging for .NET Core / standard projects (doc)
  • automatic detection and execution of .NET Core test projects. This part of just deployed last weekend and we are looking for feedback.

Next step we are working on is automatic ASP.NET core projects publishing.

@PaitoAnderson

This comment has been minimized.

Copy link

commented Oct 25, 2017

@IlyaFinkelshteyn Works for me! 👍

Previously I had this test_scripts section, but I removed it they still all ran.

test_script:
- cmd: >-
    dotnet test src/XXX.Tests

    dotnet test src/XXX.Tests
@bkoelman

This comment has been minimized.

Copy link

commented Oct 26, 2017

After changing Tests > Test assemblies to Automatically discovered, I am getting:

Build started
git clone -q --branch=master https://github.com/bkoelman/TestableFileSystem.git C:\projects\testablefilesystem
git checkout -qf f508d98c20365fbe62199cec5f7c3164ec51e64d
Patching .NET Core .csproj files
Object reference not set to an instance of an object.

https://ci.appveyor.com/project/bkoelman/testablefilesystem/build/0.1.0-pre-116-master

@IlyaFinkelshteyn

This comment has been minimized.

Copy link
Member Author

commented Oct 26, 2017

@bkoelman please use Previous Visual Studio 2017 and watch this issue for proper fix. Sorry for the trouble.

@scottdorman

This comment has been minimized.

Copy link

commented Nov 6, 2017

It looks like the automatic discovery of .net core tests is working, in as much as it discovers that there are tests to be run. However, it still seems to be failing (see the build here).

Discovering tests...OK

Running .NET Core tests...dotnet test "C:\projects\cadru\tests\Cadru.IO.Tests\Cadru.IO.Tests.csproj" --configuration Debug --no-build

Test run for C:\projects\cadru\tests\Cadru.IO.Tests\bin\Any CPU\Debug\netcoreapp1.1\Cadru.IO.Tests.dll(.NETCoreApp,Version=v1.1)

Microsoft (R) Test Execution Command Line Tool Version 15.3.0-preview-20170628-02

Copyright (c) Microsoft Corporation.  All rights reserved.


The test source file "C:\projects\cadru\tests\Cadru.IO.Tests\bin\Any CPU\Debug\netcoreapp1.1\Cadru.IO.Tests.dll" provided was not found.

Command exited with code 1

Attempting to work around this issue for now by adding APPVEYOR_BLOCK_DOTNETCORE_TESTS_AUTORUN: true to my appveyor.yml file.

scottdorman added a commit to scottdorman/cadru that referenced this issue Nov 6, 2017

@IlyaFinkelshteyn

This comment has been minimized.

Copy link
Member Author

commented Nov 8, 2017

@casz casz referenced this issue Dec 12, 2017

Merged

Create appveyor.yml #36

ronniehicks added a commit to ronniehicks/media-collection-library-api that referenced this issue Feb 20, 2018

Update appveyor.yml
The `dotnet restore` is a temporary measure. appveyor/ci#1404
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.