You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At my employer, the developers have hit our collective heads on the dreaded "Could not load file or assembly..." error so many times that policy is to ensure that <_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput> is added to any Azure Functions csproj any time a new function app is created.
The fact that this is necessary, at all, ever, is a monumental failing on the part of the Functions team. Features that are enabled by default should not break your app! This "cleaning your build output" is not helpful, it is not safe, it is not sane, and it should absolutely never have been implemented as a default.
FunctionsPreservedDependencies is a worthless attempt to fix the problem you guys created by forcing devs to manually pick through their dependencies, list them, then repeat the same every time they update a NuGet package. I don't have the time to waste on that, I just want my code to work without having to jump through pointless hoops. Just like how pretty much everything else in the .NET stack works, in other words.
If you aren't going to make the build-cleaning algorithm smart enough to not cause dependency load issues (which you haven't done despite this being a problem for years, hence I assume it's never going to happen) then disable it by default. Stop inflicting the pain of a completely unnecessary and unhelpful "solution" onto developers who are just trying to be productive. We have enough problems, we don't need the tooling we rely on to give us more.
The number of man-hours that have been wasted by developers encountering this issue, by bug reports posted to this repo, by your team replying to those bug reports could all have been avoided if you'd just done the sane thing and disabled it. So please, do it for Functions v6.
The text was updated successfully, but these errors were encountered:
Hi @IanKemp , Thank you for your feedback, We apologies for the inconvenience, We understand that there are lot of gaps that are being slowly addressed, and make sure they work. The isolated model is another way of approach with a better experience and although there are gaps today, It's a lot more aligned with the way that net stack typically works.
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.
At my employer, the developers have hit our collective heads on the dreaded "Could not load file or assembly..." error so many times that policy is to ensure that
<_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>
is added to any Azure Functions csproj any time a new function app is created.The fact that this is necessary, at all, ever, is a monumental failing on the part of the Functions team. Features that are enabled by default should not break your app! This "cleaning your build output" is not helpful, it is not safe, it is not sane, and it should absolutely never have been implemented as a default.
FunctionsPreservedDependencies
is a worthless attempt to fix the problem you guys created by forcing devs to manually pick through their dependencies, list them, then repeat the same every time they update a NuGet package. I don't have the time to waste on that, I just want my code to work without having to jump through pointless hoops. Just like how pretty much everything else in the .NET stack works, in other words.If you aren't going to make the build-cleaning algorithm smart enough to not cause dependency load issues (which you haven't done despite this being a problem for years, hence I assume it's never going to happen) then disable it by default. Stop inflicting the pain of a completely unnecessary and unhelpful "solution" onto developers who are just trying to be productive. We have enough problems, we don't need the tooling we rely on to give us more.
The number of man-hours that have been wasted by developers encountering this issue, by bug reports posted to this repo, by your team replying to those bug reports could all have been avoided if you'd just done the sane thing and disabled it. So please, do it for Functions v6.
The text was updated successfully, but these errors were encountered: