Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Azure Functions Project Fails Build Because of Output Assembly Location
dwallace
#1 Posted : Thursday, November 16, 2017 7:57:51 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/16/2017(UTC)
Posts: 3
Location: United States of America

Was thanked: 1 time(s) in 1 post(s)
I understand that Azure projects are not officially supported by NCrunch. This problem seems to be one that, while encountered here in an Azure Functions project, could just as well occur in a non-Azure project.

Reproduction of this issue is easy. Here are the steps:

1. Create a new Visual Studio project using the built in “Azure Functions” template. (This template is listed under the “Cloud” folder in the New Project dialogue box.)
2. Build the project. No modifications necessary. It will build successfully.
3. Enable NCrunch using the default settings.
4. NCrunch gives an immediate build failure message.

The problem seems to be that if a project build happens to put the new assembly in a subdirectory of the project output directory rather than directly in the root, NCrunch will fail to find it. In the example case above, the project created by the built-in VS template for Azure Functions, will place it’s output file in a subfolder called “<project name>\bin\Debug\net461\bin” rather than directly in the root output folder (<project name>\bin\Debug\net461). NCrunch apparently does not recursively check any subfolders for the file.

I located a discussion on this issue (with the exception that NCrunch isn’t involved) in the Azure Functions Github site at: https://github.com/Azure...re-Functions/issues/441

One of the project maintainers appears to believe that their side of the issue has been addressed. This does not appear to be the case (at least from the NCrunch perspective).

Any guidance would be appreciated.
Remco
#2 Posted : Thursday, November 16, 2017 10:24:03 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
Hi, thanks for posting.

This issue is specific to Azure/Azure Functions. When NCrunch builds a project, it integrates with the build and interrogates it for information about where the primary output assembly is located. Because the location is configurable, it isn't safe for NCrunch to assume that it will fall under bin\debug, or even under the project directory itself (sometimes it can be a relative path upwards of the project directory).

This integration only works because it's been rigorously tested with all supported project types. Under Azure, there has been no such testing, and from problems that have been reported it's clear that Azure's build logic is quite different to that of any other project type.

Adding support for a project type such as Azure is quite an undertaking because it involves building test cases for all possible/likely build structures used by all versions of Azure, then committing additional time to tracking down those use cases that can't be easily identified up-front. This is in addition to the actual work required to implement support. At the moment with the level of platform instability we've seeing (VS/.NET Core), we just don't have the development capacity to introduce such support or to try and tackle Azure-related problems on a case by case basis. I'm sorry but I just can't help with this problem.
dwallace
#3 Posted : Saturday, November 18, 2017 2:28:15 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/16/2017(UTC)
Posts: 3
Location: United States of America

Was thanked: 1 time(s) in 1 post(s)
Thank you, Remco. No need to apologize.

I appreciate you taking the time to reply. I’m sure this information will be useful for other devs as they encounter these issues.

While I am disappointed that I can’t use NCrunch for my Azure projects, I’m glad to have a more clear understanding of the tool. I also appreciate that you recognize your resource limitations and define support boundaries accordingly. As a customer, I’d prefer the product be limited in capability, but solid, rather than flimsy because the author has over-committed.

My hope was that NCrunch could be my only test runner, but as I discover the limitations, it looks like more of a “right tool for the job” product. I’ll continue to use it for my “core” (clean code/hexagonal design) and I’ll revert back to a more traditional runner for my outer layer infrastructure/framework projects.

You’ve got a great product. I hope with the seeming stabilization of things with .net core 2, you’ll be able to return to more normal dev and support situation.
1 user thanked dwallace for this useful post.
Remco on 11/18/2017(UTC)
cross
#4 Posted : Tuesday, May 1, 2018 1:32:39 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 5/1/2018(UTC)
Posts: 3
Location: United Kingdom

Hi,
I'm hitting this same problem. Has there been any progress or suggested fixes over the last 5 months. I'm using Azure Functions v1 and would like to continue using NCrunch.
Thanks,
Colin
Remco
#5 Posted : Tuesday, May 1, 2018 9:27:21 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
Hi Colin,

I'm sorry but as discussed above, this project type is not supported by NCrunch.
cross
#6 Posted : Wednesday, May 2, 2018 1:02:11 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 5/1/2018(UTC)
Posts: 3
Location: United Kingdom

Hi Remco,
Thanks for posting your response. I understand your reasoning behind not supporting Azure projects. We're all subject to the moving target that is Azure and have been bitten as a result. However, as well as the numerous configuration options within NCrunch, would adding the ability to customise the path to the output assembly be a simple solution? This avoids the need for you to test compatibility with Azure project types but lets the end user resolve project path issues when encountered? And your excellent documentation would include suitable warnings.
More and more corporate development houses are targeting Azure solutions and it would be a shame to lose the excellent NCrunch functionality (not a fan of VS Live Unit Testing).
Yours hopefully,
Colin
cross
#7 Posted : Wednesday, May 2, 2018 1:57:04 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 5/1/2018(UTC)
Posts: 3
Location: United Kingdom

I.e. The path to my normal .net framework project is: \bin\Debug\net461 - this works fine in ncrunch
The path to an azure function SDK generated project is: \bin\Debug\net461\bin - it would be great if I could configure the additional bin folder.

Of course this simple change is no doubt not simple...
Cheers,
Colin
Remco
#8 Posted : Wednesday, May 2, 2018 7:57:06 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
Hi Colin,

Unfortunately, it's never that simple.

The path to the binary is normally identified by NCrunch by examining build properties provided by MSBuild. In this way, we can always find the output file as it's generated by the build system.

Unfortunately, this project type does not follow the same system as other project types supported by NCrunch. The difference in output path is the result of vastly different logic within MSBuild, it's essentially a symptom of a much bigger problem, and is likely just the tip of the iceberg as far as potential problems go with adding support for this project type.

By trying to implement a quick-fix as you're suggesting, we'd soon end up in a situation where something else doesn't work, or other edge cases fail. It isn't really possible to implement part-way solutions when dealing with project compatibility, and taking such an approach creates frustration for everyone involved.

I'm sorry but I cannot provide support for this project type.
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.048 seconds.