Azure Function : build issue

Hello,

I'm testing for my company Ncrunch vs R# Continuous Testing before purshasing licence for every developers.
For now, Ncrunch is far better for me but it does not work with Azure Functions :(

It looks like Ncrunch is not looking the good path to find the dll, in my code exemple Ncrunch looks here :
C:\Users\Bigmat\AppData\Local\NCrunch\17028\9\MyFunction\bin\Debug\netcoreapp2.2\MyFunction.dll

but the real path is :
C:\Users\Bigmat\AppData\Local\NCrunch\17028\9\MyFunction\bin\Debug\netcoreapp2.2\bin\MyFunction.dll

Is it possible to force the path where to look ? or Add this path on your side to check on ?

If someone has any work around I'm very interested because Azure Function is used a lot in our company.

Regards,
Mathieu

Hi, thanks for sharing this issue.

Unfortunately, the Azure platform (and its function projects) is not supported by NCrunch. I'm afraid that I can't offer any workaround to this problem.

It looks like Azure function support is a requested feature at the moment.

It's entirely possible that someone in the community knows of a workaround for this problem and is able to provide advice, but from the product side, unfortunately I can't help here.

I succeeded in having a Function App build within NCrunch by adding the following to the Function csproj:

<Target Name="NCrunchBuild" AfterTargets="_GenerateFunctionsPostBuild" Condition=" '$(Configuration)' == 'Debug' ">
<Exec Command="xcopy /y &quot;$(TargetDir)bin\$(TargetName).*&quot; &quot;$(TargetDir)&quot;" />
</Target>

and setting the configuration parameter "Copy reference assemblies to workspace" to true (for the Function App project only).

If I don't set this setting, NCrunch build is unable to resolve NuGet assemblies.

But this may decrease NCrunch performances...

arkiaconsulting wrote:I succeeded in having a Function App build within NCrunch by adding the following to the Function csproj:

<Target Name="NCrunchBuild" AfterTargets="_GenerateFunctionsPostBuild" Condition=" '$(Configuration)' == 'Debug' ">
<Exec Command="xcopy /y &quot;$(TargetDir)bin\$(TargetName).*&quot; &quot;$(TargetDir)&quot;" />
</Target>

and setting the configuration parameter "Copy reference assemblies to workspace" to true (for the Function App project only).

If I don't set this setting, NCrunch build is unable to resolve NuGet assemblies.

But this may decrease NCrunch performances...

Thanks for the useful target.

If you remove the Debug condition when publishing with dotnet CLI, don't forget to add --no-build switch to avoid twice copy.

Here is mine, a shorter one for paths and triggered only for the ncrunch build :

  <Target Name="CopyAzureFunctionOutput" AfterTargets="_GenerateFunctionsPostBuild" Condition="'$(NCrunch)' == '1'">
    <Exec Command="xcopy /y &quot;$(OutDir)\bin&quot; &quot;$(OutDir)&quot;" />
  </Target>

If you have multiple azure functions projet, you can also add this target inside a Directory.Build.targets file to apply the target on all projects.

I was facing to a bigger problem than just copy some moved binaries with the azure functions targets :

Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'Microsoft.Azure.WebJobs.Extensions.Http, Version=3.0.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

I have done a better version in order to skip directly the Microsoft.NET.Sdk.Functions targets; here is the details :
In the obj folder, a file <project>.nuget.g.targets contains the associated imported targets like that :

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
  </PropertyGroup>
  <ImportGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
    <Import Project="$(NuGetPackageRoot)netstandard.library\2.0.3\build\netstandard2.0\NETStandard.Library.targets" Condition="Exists('$(NuGetPackageRoot)netstandard.library\2.0.3\build\netstandard2.0\NETStandard.Library.targets')" />
    <Import Project="$(NuGetPackageRoot)microsoft.extensions.configuration.usersecrets\3.1.2\build\netstandard2.0\Microsoft.Extensions.Configuration.UserSecrets.targets" Condition="Exists('$(NuGetPackageRoot)microsoft.extensions.configuration.usersecrets\3.1.2\build\netstandard2.0\Microsoft.Extensions.Configuration.UserSecrets.targets')" />
    <Import Project="$(NuGetPackageRoot)microsoft.azure.webjobs.script.extensionsmetadatagenerator\1.1.5\build\Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.targets" Condition="Exists('$(NuGetPackageRoot)microsoft.azure.webjobs.script.extensionsmetadatagenerator\1.1.5\build\Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.targets')" />
    <Import Project="$(NuGetPackageRoot)microsoft.net.sdk.functions\3.0.5\build\Microsoft.NET.Sdk.Functions.targets" Condition="Exists('$(NuGetPackageRoot)microsoft.net.sdk.functions\3.0.5\build\Microsoft.NET.Sdk.Functions.targets')" />
  </ImportGroup>
</Project>

As you can see, to disable the targets loading, you can set the ExcludeRestorePackageImports property to true in your project referencing the azure function package like this:

  <PropertyGroup Condition="'$(NCrunch)' == '1'">
    <ExcludeRestorePackageImports>true</ExcludeRestorePackageImports>
  </PropertyGroup>

That way, the targets is not triggered, the files are not moved into the bin folders and NCrunch works fine.

Is this still needed in 2023 with NCrunch v4.16 testing Azure Functions v4 with TargetFramework net6.0?

We have older projects that have been migrated from v3 with TargetFramework netcoreapp3.1 to current versions having configured the two blocks from above and we have current projects not having this blocks.
It seems it makes no difference at all and those entries can be removed.

GlobalConcepts wrote:Is this still needed in 2023 with NCrunch v4.16 testing Azure Functions v4 with TargetFramework net6.0?

No. We implemented a slightly more streamlined version of the above workaround into NCrunch itself, so you shouldn't need to have additional engineering in your project files to make this work now.