This appears to be rather big news as there will be some semblance of software parity between Win and Mac platforms - the rebranding of MonoDevelop appearing to have been a stop gap solution for the Mac platform. MS dumps the Mono runtime for .Net 6. Are there any plans to have Fire Elements work within Visual Studio 2022 for Mac as Water has been working with Visual Studio for Windows? Exciting times 
Just to clarify on the naming, Fire and Water our our IDEs (for Mac and Windows, respectively), separate from Visual Studio. Elements is the compiler, and it works in Fire, Water, and Visual Studio for Windows.
As for supporting the new Visual Studio for Mac: we’ll have to have a look, but id say unless this literally is the same Visual Studio as on Windows, with the same extension APIs, i would say chances are slim that we’ll add support for it.
Adding and supporting a new IDE is a lot of effort (and supporting VS/Windows is the largest effort between the three IDEs, and that’s taking into account that we (i) wrote Fire/Water from scratch), so i’m hesitant to add new workloads here, especially since i don’t expect demand for this to be huge (as, i think/hope, people are generally pretty happy with Fire). Also, i don’t believe anyone on our current VS team uses/has Macs at all, which adds another burden there.
But that said, if it’s “the same” VS as VS/Windows, and our existing support for it more or less “just works” as is, we migh.
1 Like
Not a good first impression so far ;).
Installer looks nice, VS only seems to know one project template type for some reason (“Azure Function”), and trying to create it fails with
Unable to locate the .NET SDK. Check that it is installed and that the version specified in global.json (if any) matches the installed version."
even though .NET 6 is installed and setup for some reason also installed .NET Core 3.0.1, as well.
Opening existing VC# projects works, but the IDE doesn’t;t look.feel anything like VS/Windows (which is good, in general), which makes me think supporting this will not be as simple as using our existing plugins. I think this is still based MonoDevelop, just evolved a lot.
Ah, if anyone cares, in Preferences the SDK location is set to /Applications/Visual Studio (Preview).app/dotnet, when it should be /Applications/Visual Studio (Preview).app/Content/dotnet. Changing that still doesn’t fix it 
1 Like
It also still seems to be running on Mono. Not that that’s bad; Mono is solid, and Fire still uses that (and will continue to use to for the foreseeable).
1 Like
Sorry about using the IDE names vs “Elements Compiler”, the names just sound sexier. 
I’m just getting a chance to play with VS 2022 for Mac as we speak(or write), my MBP was out of commission for a while, right shift key permanently disabled. But I’d have to agree with you. It feels like a more evolved Monodevelop which is not a bad thing at all. 
I confirm that I see it in the location you indicated:
But it appears the IDE is directing me here as well:
I am, although I would like some support for azure and aws. I would also like to see Fire running using .net core. I wrote some azure and aws functions in Fire. It takes a bit of work but I do have working code. I think for azure it might be a bit more tricky because it appears to be tied into msbuild.
Agreed. it does feel more Mac like than id expected, which is good for VS users. Its just bad news in terms of us erasing our integration.
I noticed one odd thing: after installing VS/Mac, I could no longer open solutions in Fire, the OS claiming Fire didn’t know how to open the “Visual Studio project structure” format.” After deleting VS again it’s fine.
Somehow VS seems to mess with how it registers the file extension that breaks other apps; so far I couldn’t figure out why, or what I could do about it. Did you notice that too, or is all still fine for you?
ah it wants the exe, not the folder, so I guess is should have put in /Applications/Visual Studio (Preview).app/Content/dotnet/dotnet . 
I do have the system-wide install too of course, odd it didn’t use that one here. Ah well…
I’d love to hear more on what you’d like supported here, in a separate thread. I assume mainly publishing options?
What benefit would you see from that, aside from maybe marginal performance improvements if .NET Core 6/7 runs faster than Mono (and that’d an if, I’m not seeing many performance issues from the managed code)?
Cool. lets have a look at that in a fresh thread. 
1 Like
Just to wrap this thread up, I did a quick “Hello World” dotnet6 test. Appears to be working as expected. And no I don’t type that slowly - I’m having to use the left shift key for everything. 
Lol. I don’t think I’ve ever once used the right shift key.
1 Like
I don’t know of any technical reason, it would just be nice to that its using the latest .net rather than something that appears to be no longer supported.
Yeah, thats abut a month or two of work for “would just be nice” ;). Fire deeply depends on Marzipan for Mono/Native interop. We’ll basically have to reinvent that from scratch for .NET Core, and that will be a major undertaking…
So… eventually, sure. any time soon? probably not.