I have a new project which works in my local Visual Studio debug mode. I used this document https://docs.aspnetzero.com/en/aspnet-core-mvc/latest/Setting-Up-an-Azure-Pipeline-Mvc-Core to configure my Azure pipeline. The app builds and deploys, but when I browse to it I see the login page with the wrong font and the "Log In" button does not work. I look at the browser Developer Mode to find errors being thrown like this:

This looks like the problem I first had when I started the project without running yarn or NPM. I have the yarn and NPM in my pipeline definition. Perhaps there is a clue in the output log (in the Pipeline log), because I don't know whether remarks like "The platform "win32" is incompatible with this module" (in the yarn log) are important:

yarn Build Job

##[debug]Getting credentials for local feeds SYSTEMVSSCONNECTION exists true ##[debug]SYSTEMVSSCONNECTION exists true ##[debug]Got auth token ##[debug]System.ServerType=Hosted ##[debug]Agent.ProxyUrl=undefined ##[debug]Getting URI for area ID 4C83CFC1-F33A-477E-A789-29D38FFCA52E from https://-myAzure-.visualstudio.com/ ##[debug]Getting credentials for local feeds SYSTEMVSSCONNECTION exists true ##[debug]SYSTEMVSSCONNECTION exists true ##[debug]Got auth token ##[debug]Agent.ProxyUrl=undefined ##[debug]Acquiring Packaging endpoints from https://-myAzure-.pkgs.visualstudio.com/ ##[debug]Successfully acquired the connection data ##[debug]Acquired location ##[debug]{"PackagingUris":["https://-myAzure-.visualstudio.com/","https://-myAzure-.pkgs.visualstudio.com/","https://pkgsprodeau1.pkgs.visualstudio.com/","https://-myAzure-.pkgs.visualstudio.com/","https://-myAzure-.pkgs.visualstudio.com/","https://pkgs.dev.azure.com/-myAzure-/"],"DefaultPackagingUri":"https://-myAzure-.pkgs.visualstudio.com/"} ##[debug]C:\npm\prefix\yarn.cmd ##[debug]Build.BuildId=1378 ##[debug]Agent.BuildDirectory=d:\a\1 ##[debug]testing directory 'd:\a\1\npm' ##[debug]testing directory 'd:\a\1' ##[debug]mkdir 'd:\a\1\npm' ##[debug]Using registries in .npmrc ##[debug]customEndpoint=null ##[debug]which 'yarn' ##[debug]found: 'C:\npm\prefix\yarn.cmd' ##[debug]which 'yarn' ##[debug]found: 'C:\npm\prefix\yarn.cmd' ##[debug]ProductionMode=false ##[debug]OverridingProjectNpmrc: d:\a\1\s\src\DMux.WebPortal.Web.Mvc.npmrc ##[debug]rm -rf d:\a\1\s\src\DMux.WebPortal.Web.Mvc.npmrc ##[debug]exec tool: C:\npm\prefix\yarn.cmd ##[debug]arguments: C:\windows\system32\cmd.exe /D /S /C "C:\npm\prefix\yarn.cmd" yarn install v1.19.1 warning package.json: No license field warning [email protected]: No license field [1/4] Resolving packages... [2/4] Fetching packages... warning [email protected]: Unable to read "./man" directory of module "json2" warning [email protected]: Unable to read "./man" directory of module "joosex-simplerequest" warning [email protected]: Unable to read "./man" directory of module "joose" warning [email protected]: Unable to read "./man" directory of module "joosex-namespace-depended" info [email protected]: The platform "win32" is incompatible with this module. info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation. [3/4] Linking dependencies... warning " > [email protected]" has incorrect peer dependency "bootstrap@^3.1.1". warning " > [email protected]" has incorrect peer dependency "[email protected]". warning "js-url > [email protected]" has unmet peer dependency "grunt@>=1.0.3". [4/4] Building fresh packages... Done in 63.61s. ##[debug]Exit code 0 received from tool 'C:\npm\prefix\yarn.cmd' ##[debug]STDIO streams have closed for tool 'C:\npm\prefix\yarn.cmd' ##[debug]rm -rf d:\a\1\s\src\DMux.WebPortal.Web.Mvc.npmrc ##[debug]removing file ##[debug]RestoringProjectNpmrc ##[debug]Agent.BuildDirectory=d:\a\1 ##[debug]rm -rf d:\a\1\npm\1378.npmrc ##[debug]removing file ##[debug]task result: Succeeded ##[debug]Processed: ##vso[task.complete result=Succeeded;]Yarn executed successfully ##[debug]Agent.BuildDirectory=d:\a\1 ##[debug]rm -rf d:\a\1\npm ##[debug]removing directory Finishing: Yarn

NPM Build Job

##[debug]Evaluating condition for step: 'NPM Build Job' ##[debug]Evaluating: succeeded() ##[debug]Evaluating succeeded: ##[debug]=> True ##[debug]Result: True Starting: NPM Build Job

Task : Command line Description : Run a command line script using Bash on Linux and macOS and cmd.exe on Windows Version : 2.151.2 Author : Microsoft Corporation Help : https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/command-line

##[debug]VstsTaskSdk 0.9.0 commit 6c48b16164b9a1c9548776ad2062dad5cd543352 ##[debug]Entering D:\a_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.151.2\cmdline.ps1. ##[debug]Loading resource strings from: D:\a_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.151.2\task.json ##[debug]Loaded 6 strings. ##[debug]SYSTEM_CULTURE: 'en-US' ##[debug]Loading resource strings from: D:\a_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.151.2\Strings\resources.resjson\en-US\resources.resjson ##[debug]Loaded 6 strings. ##[debug]INPUT_FAILONSTDERR: 'false' ##[debug] Converted to bool: False ##[debug]INPUT_SCRIPT: 'cd src/DMux.WebPortal.Web.Mvc ##[debug]npm run build' ##[debug]INPUT_WORKINGDIRECTORY: 'd:\a\1\s' ##[debug]Asserting container path exists: 'd:\a\1\s' Generating script. ##[debug]AGENT_VERSION: '2.159.2' ##[debug]AGENT_TEMPDIRECTORY: 'd:\a_temp' ##[debug]Asserting container path exists: 'd:\a_temp' ##[debug]Asserting leaf path exists: 'C:\windows\system32\cmd.exe' ========================== Starting Command Output =========================== ##[debug]Entering Invoke-VstsTool. ##[debug] Arguments: '/D /E:ON /V:OFF /S /C "CALL "d:\a_temp\42efb6de-fddf-4c1d-becb-0056851d297f.cmd""' ##[debug] FileName: 'C:\windows\system32\cmd.exe' ##[debug] WorkingDirectory: 'd:\a\1\s' "C:\windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "d:\a_temp\42efb6de-fddf-4c1d-becb-0056851d297f.cmd""

[email protected] build D:\a\1\s\src\DMux.WebPortal.Web.Mvc gulp build

[02:35:56] Using gulpfile D:\a\1\s\src\DMux.WebPortal.Web.Mvc\gulpfile.js [02:35:56] Starting 'build'... [02:37:55] Finished 'build' after 1.97 min ##[debug]Exit code: 0 ##[debug]Leaving Invoke-VstsTool. ##[debug]Leaving D:\a_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.151.2\cmdline.ps1. Finishing: NPM Build Job

In my Release definition I have this as the "Package or Folder" to deploy:

$(System.DefaultWorkingDirectory)**\DMux.WebPortal.Web.Mvc.zip

Should I include other files...?

Can someone please point me in the right direction?

• Kevin

My unit tests all work in Visual Studio, but I get errors in the Azure pipeline.

This is the error with some possible clues in the preceeding lines:

Test run will use DLL(s) built for framework .NETCoreApp,Version=v2.2 and platform X86. Following DLL(s) do not match framework/platform settings. xunit.runner.visualstudio.dotnetcore.testadapter.dll is built for Framework 1.0 and Platform AnyCPU. xunit.runner.visualstudio.dotnetcore.testadapter.dll is built for Framework 1.0 and Platform AnyCPU. xunit.runner.visualstudio.dotnetcore.testadapter.dll is built for Framework 1.0 and Platform AnyCPU. Go to http://go.microsoft.com/fwlink/?LinkID=236877&clcid=0x409 for more details on managing these settings. ##[error]Unable to find d:\a\1\s\test\DMux.WebPortal.GraphQL.Tests\bin\Debug\netcoreapp2.2\DMux.WebPortal.GraphQL.Test.Base.deps.json. Make sure test project has a nuget reference of package "Microsoft.NET.Test.Sdk". ##[debug]Processed: ##vso[task.logissue type=error;]Unable to find d:\a\1\s\test\DMux.WebPortal.GraphQL.Tests\bin\Debug\netcoreapp2.2\DMux.WebPortal.GraphQL.Test.Base.deps.json. Make sure test project has a nuget reference of package "Microsoft.NET.Test.Sdk".

The project does have the Nuget package:

But I wonder if the AnyCPU is relevant? My Pipeline is configured for AnyCPU, and the unit test project is too.

Can someone suggest anything?

• Kevin

This one is resolved now.

I updated Microsoft.NET.Test.Sdk to 16.3.0 (from 16.2.0). This changed the error messages, which led me to the solution. The wildcard selection of DLLs in the Azure test selection picks up xUint DLLs as well. Changing the selection is the solution, which I learned from this advice https://xunit.net/docs/getting-test-results-in-azure-devops

I found that I could not figure out what all the exclusions would need to be (The ones listed in that website didn't seem sufficient), so instead I explicitly specified the MyProjectTests.dll file without a wildcard.

Unit tests now run in Azure.

This is now resolved.

The errors arose because none of the minified .js files were on the app service. I'm guessing that's what NPM does, but i don't know why I wasn't getting them deployed.

In the end I found that, although I thought it not relevant, I had some differences in my pipeline from the configuration in https://docs.aspnetzero.com/en/aspnet-core-mvc/latest/Setting-Up-an-Azure-Pipeline-Mvc-Core

When I went back and set mine up precisely as that document recommends it works.

I had used the Pipeline created by Visual Studio "Configure Continuous Depoyment", and adapted it. It uses different tools for the build and test, so there must be some difference there.

tl;dr: it's resolved.

When querying the App Services as an API call, the return object looks like this:

{ "result": { -The serialized POCO object Swagger is advertising- }, "targetUrl": string, "success": bool, "error": string, "unAuthorizedRequest": bool, "__abp": bool }

While it's easy enough to unwrap the object once you know what to expect, unfortunately the auto-generated client code created by the Swagger/NSwag tool creates code which is broken because it is not expecting the wrapper. This means if I regenerate the client code I need to go through it fixing the deserialisation routines again.

Can we somehow tell Swagger to include the wrapper object in its advertised schema? This would mean the generated code would automatically have the correct objects to deserialise correctly (It would also mean Swagger reports its schema truthfully, which seems desirable).

Perfect! Thank you.

Angular wasn't what I needed - I'm creating a data transfer client, not a UI. But in the article you linked to, this was precisely what I hoped for:

AbpAspNetCore().DefaultWrapResultAttribute.WrapOnSuccess = false;

Apparently ASPNetZero used to include meronic's Calendar control but no longer includes it. Is this correct?

If so, how do I install https://fullcalendar.io/ into my MVC DontNet Core v7.2.0 project?

I have tried a bunch of things from instructions I found online. The instructions I found seemed to assume things that were not valid in my project and I didn't know how to resolve the issues. It seems the instructions all assume Angular.

Can someone provide steps that will suit my project?

On further searching I found this fiddle: https://dotnetfiddle.net/1ganYd, which gave me the pieces that seem to work, no installation packages required!

I have everything in the .html file at the moment and the calendar appears, so now I'll put everything in the right places.

Leaving this here in case anyone else needs it.

It's up! Version 8.0 with Core 3.0 support is available for download.

I just downloaded the v8.0 project and all went smoothly. Thanks team, I've been waiting for this so that I can add my OData support!

I am exploring the new Customizable Dashboards and I'm excited about implementing this feature.

I noticed that if my user does not have the AppPermissions.Pages_Administration_AuditLogs permission, the dashboard does not get populated and they have no widgets available. (I note the generalStats widget adds the AppPermissions.Pages_Administration_AuditLogs to its permissions but I can't see why that would cause a problem).

I managed to work around this in the short term by adding the AppPermissions.Pages_Tenant_Dashboard permission to the AuditLogAppService, but I couldn't see exactly where this dependency was introduced. Of course, my workaround is not ideal, so maybe someone can identify the root cause.

Also a question: I am looking at setting up a library of widgets as partial html files, which are inserted at runtime. But is this something you guys are planning to develop soon? If so I'll hold off and just keep using the pattern you have set up so that upgrades are simpler.