Re: Blazor deploy error

[Greg Keogh]

>
> https://blog.greglow.com/2018/02/13/opinion-theres-plague-need-stop/
>

Ha! I owe you a drink. I thought I was crazy, but I'm relieved to know I'm
not alone -- *GK*

>

RE: Blazor deploy error

[Dr Greg Low]

https://blog.greglow.com/2018/02/13/opinion-theres-plague-need-stop/


Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410 mobile
SQL Down Under | Web: https://sqldownunder.com | 
About Greg:  https://about.me/greg.low

From: Greg Keogh via ozdotnet 
Sent: Wednesday, 6 July 2022 12:43 PM
To: ozDotNet 
Cc: Greg Keogh 
Subject: Re: Blazor deploy error

After hours of ruling out a mistake on my part, or some change in the compile 
and hosting options, the only thing left is the tooling. Adjusting my searches 
slightly and haphazardly, I finally stumbled upon this 
post from a few weeks ago.

Some are blaming spaces in paths, maybe, but I'm using SDK 6.0.301 which people 
are blaming for introducing this problem. There are some angry comments.

I downloaded and installed SDK 6.0.5 with 6.0.300, then ran the command dotnet 
new globaljson --force --sdk-version 6.0.300 which creates a global.json file 
as suggested. Clean project, rebuild, now it deploys.

The hours of suffering I wasted on this is apparently caused by some bug in the 
donet command, which someone says will be fixed 6.0.2.

I'm shitting bricks and spitting chips, because here we are in 2022 and we get 
error messages like An error has occured with not the slightest clue anywhere 
about what has gone wrong. In the early 1980s we used to get mainframe messages 
like "JDE833 Program aborted", but even then I could look up the error in a 
manual and do something useful. Is this progress?!

Greg K

Re: It's that time of year - F#

[Greg Keogh]

>
> [cut]
> ...Language Service Protocol (LSP) for sharing across VS and VS Code.
>

Now that's an interesting subject I didn't know about. Language Server
Protocol  * Official
Page  (shame it's
based on JSON) -- *Greg K*

Re: Blazor deploy error

[mike smith]

Unhappy memories of "redo from start"

On Wed, 6 July 2022, 12:15 Greg Keogh via ozdotnet, 
wrote:

> After hours of ruling out a mistake on my part, or some change in the
> compile and hosting options, the only thing left is the tooling. Adjusting
> my searches slightly and haphazardly, I finally stumbled upon this post
>  from a few weeks ago.
>
> Some are blaming spaces in paths, maybe, but I'm using SDK 6.0.301 which
> people are blaming for introducing this problem. There are some angry
> comments.
>
> I downloaded and installed SDK 6.0.5 with 6.0.300, then ran the command dotnet
> new globaljson --force --sdk-version 6.0.300 which creates a
> global.json file as suggested. Clean project, rebuild, now it deploys.
>
> The hours of suffering I wasted on this is apparently caused by some bug
> in the donet command, which someone says will be fixed 6.0.2.
>
> I'm shitting bricks and spitting chips, because here we are in 2022 and we
> get error messages like *An error has occured* with not the slightest
> clue anywhere about what has gone wrong. In the early 1980s we used to get
> mainframe messages like "JDE833 Program aborted", but even then I could
> look up the error in a manual and do something useful. Is this progress?!
>
> *Greg K*
> --
> ozdotnet mailing list
> To manage your subscription, access archives: https://codify.mailman3.com/

Re: Blazor deploy error

[Greg Keogh]

After hours of ruling out a mistake on my part, or some change in the
compile and hosting options, the only thing left is the tooling. Adjusting
my searches slightly and haphazardly, I finally stumbled upon this post
 from a few weeks ago.

Some are blaming spaces in paths, maybe, but I'm using SDK 6.0.301 which
people are blaming for introducing this problem. There are some angry
comments.

I downloaded and installed SDK 6.0.5 with 6.0.300, then ran the command dotnet
new globaljson --force --sdk-version 6.0.300 which creates a
global.json file as suggested. Clean project, rebuild, now it deploys.

The hours of suffering I wasted on this is apparently caused by some bug in
the donet command, which someone says will be fixed 6.0.2.

I'm shitting bricks and spitting chips, because here we are in 2022 and we
get error messages like *An error has occured* with not the slightest clue
anywhere about what has gone wrong. In the early 1980s we used to get
mainframe messages like "JDE833 Program aborted", but even then I could
look up the error in a manual and do something useful. Is this progress?!

*Greg K*

Re: Blazor deploy error

[Greg Keogh]

>
> Sorry, perhaps dumb question, but what does it say in the Output window?
>

It says "dotnet.exe command failed due to build errors". But there are no
errors at all anywhere I look.

I just carefully compared my failing app to a newer smaller one that works,
and I noticed that the old targets net5.0 and the new one net6.0. Very
suspicious.

I'm now trying to upgrade to net6.0, but I'm getting weird JS runtime
errors, which is a separate hurdle, and if I get over that then I can
continue to test if the net version is the problem. Has net5.0 Blazor
support been dropped somewhere, either developer client-side or Azure
hosting server-side?!?


*Greg K*

>

RE: Blazor deploy error

[Dr Greg Low]

Sorry, perhaps dumb question, but what does it say in the Output window?

Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410 mobile
SQL Down Under | Web: https://sqldownunder.com | 
About Greg:  https://about.me/greg.low

From: Greg Keogh via ozdotnet 
Sent: Wednesday, 6 July 2022 10:23 AM
To: ozDotNet 
Cc: Greg Keogh 
Subject: Blazor deploy error

Folks, I've been trying to deploy a Blazor app from Visual Studio 2022 for 
hours without success. I'm doing the usual right-click-publish that I've been 
doing for about a year, but yesterday it stopped working, and even this morning 
with a fresh mind I cannot make any progress. I've changed the pubxml options, 
compile options, etc. Absolutely nothing works. All I get is the generic and 
utterly useless error below. Normally changing an FTP or Deploy settings :wakes 
it up" and it works, but not this time.

I'm about to delete the publish profile and make a new one, but I'm sure it's a 
waste of time. I'm wondering if some hosting versions have changed, or 
something is deprecated, something global I'm not aware of.

Has anyone been through this? -- Greg K

[cid:image001.png@01D89122.D7F20E30]

Blazor deploy error

[Greg Keogh]

Folks, I've been trying to deploy a Blazor app from Visual Studio 2022 for
hours without success. I'm doing the usual right-click-publish that I've
been doing for about a year, but yesterday it stopped working, and even
this morning with a fresh mind I cannot make any progress. I've changed the
pubxml options, compile options, etc. Absolutely nothing works. All I get
is the generic and utterly useless error below. Normally changing an FTP or
Deploy settings :wakes it up" and it works, but not this time.

I'm about to delete the publish profile and make a new one, but I'm sure
it's a waste of time. I'm wondering if some hosting versions have changed,
or something is deprecated, something global I'm not aware of.

Has anyone been through this? -- *Greg K*

[image: image.png]

Re: It's that time of year - F#

[David Kean]

Side note, Roslyn's lack of support for F# is not the lack of tail calls, it's 
the symbol/syntax model isn't designed for a language that doesn't look like C# 
or VB. Roslyn does provide higher level features for F# (and Typescript) around 
diagnostics and workspace/file views but that's being slowly replaced in lieu 
of the Language Service Protocol (LSP) for sharing across VS and VS Code.


From: David Burstin via ozdotnet 
Sent: Sunday, July 3, 2022 1:52 PM
To: ozDotNet 
Cc: Piers Williams ; David Burstin 

Subject: Re: It's that time of year - F#

Thanks Piers. I think that's an excellent summary of the F# dilemma - it is 
better but falls due to its far lower adoption. For those old enough to 
understand, it's VHS vs BetaMax.

On Sun, 3 Jul 2022 at 12:07, Piers Williams via ozdotnet 
mailto:ozdotnet@ozdotnet.com>> wrote:
I'm a bit torn on this subject.

I spent the last 3 years of the 'hands on' part of my dev career swapped over 
to F# from many, many years of writing predominantly C#, and it was a fantastic 
experience. Don Syne's main pitch these days is to think of F# as a 
productivity language first, and a FP language second, and I would support that 
view. Much of what F# pioneered in the .net space has indeed come over to C# in 
recent versions, but as a result C# syntax has grown significantly, and I see 
engineers having to talk each other out of 'bad practices' to use new idioms. 
You don't get that in F# - the 'right way' is just the default to start with, 
and you have to go out of your way to do the reverse (mutable code, 
side-affecting structures etc...). Rather than FP, just think 'nicer C#'.

That said, as a manager now, I'd have to be completely honest that it does 
present some real issues, principally around recruitment and/or ramp-up. I 
personally thought the cross-skilling was easy (~2-3 weeks), but even allowing 
for that, it's still an impost, and there is an entirely legitimate view that 
it's just one more thing engineers have to think about. F# hasn't been ported 
to Roslyn (Roslyn can't yet cope with tail calls I believe), which then 
excludes some tooling (like static analysis). And Microsoft themselves were 
gently dissuasive when the subject of using it for a particular project was 
brought up by the team.

So ultimately I think the question comes down to productivity and cognitive 
load. F# does a fantastic job (I think) of reducing those, but at the cost of 
biting off some up-front cross-skilling. The latter cost is very real and 
tangible, and the former is quite a lot harder to pin down and measure.

Ultimately in my case the engineering team came to the conclusion they had 
enough on their plate to worry about already, and I can't help but sympathise 
with that. That said, any code I write at home, or just to prove a point, I 
write in F#. I'm never going back.

Piers

On Thu, 30 Jun 2022 at 10:31, Tom Gao via ozdotnet 
mailto:ozdotnet@ozdotnet.com>> wrote:
I used F# for my doctorate as a modelling language to build out a prototype for 
a security integration platform I developed.

The problem is that there are very few people who use F# afaik. Getting any 
commercial code developed will create a problem for ongoing support. Just my 
view.

btw. this is a long shot. I'm looking for a senior digital PM in sydney does 
anyone know of anyone good who might be interested? (I'm not a recruiter but 
just desperate to get a project going)

On Fri, Jun 24, 2022 at 3:42 PM David Burstin via ozdotnet 
mailto:ozdotnet@ozdotnet.com>> wrote:
Hi folks,

It's been about a year since I asked, so here it is again. Does anyone know of 
any F# work being done in Melbourne, or anywhere in Australia?

I've managed to do some small F# helper apps for my employer, but 98% of what I 
do is C#. I'd really love to find somewhere that uses F#.

On the plus side - F# has helped improve my C# approach dramatically, and C# is 
constantly introducing more functional ideas (although discriminated unions and 
active patterns would be lovely).

So, anyone know anything?

Cheers
David
--
ozdotnet mailing list
To manage your subscription, access archives: 
https://codify.mailman3.com/
--
ozdotnet mailing list
To manage your subscription, access archives: