.NET ontwikkelen op ARM windows, te doen?

[TweakerVincent]

Ik ben werkzaam bij een klant waar ik mijn eigen laptop mag meenemen. Ik heb alleen een macbook pro met parallels windows ARM (ARM versie ivm silicon chip macos). Ik ben bang dat ik tegen beperkingen oploop als ik met de ARM versie van windows ga werken.

Ik werk nu met backend .NET Microsoft stack (C#) en integratie (Azure). .NET 5/6/7 Visual studio 2022 en vs Code.

Hoe is jullie ervaring hiermee? Ik krijg een klant laptop (aangevraagd), maar mijn macbook bevalt goed

[ Voor 3% gewijzigd door TweakerVincent op 10-02-2023 09:20 ]

[ValHallASW]

Is het dan niet handiger om op MacOS te ontwikkelen met Rider? Als het toch allemaal Azure-deployed .NET5+ is dan zal de code waarschijnlijk gewoon cross-platform zijn.

[TweakerVincent]

ValHallASW schreef op vrijdag 10 februari 2023 @ 10:32:
Is het dan niet handiger om op MacOS te ontwikkelen met Rider? Als het toch allemaal Azure-deployed .NET5+ is dan zal de code waarschijnlijk gewoon cross-platform zijn.

Ik ben Visual studio gewend (tig jaar mee gewerkt). Dus liever in windows ontwikkelen. Ik las net ergens dat ARM mss gewoon goed werkt. Zou super zijn

[SiErRa]

Los van Visual Studio licentie vraagstukken vind ik het altijd wel prettig als ik lokaal hetzelfde kan compileren als dat de build omgeving doet. Kan mij voorstellen dat je potentieel issues lokaal krijgt die op de echte omgeving er niet zijn en andersom.

[TweakerVincent]

SiErRa schreef op vrijdag 10 februari 2023 @ 10:42:
Los van Visual Studio licentie vraagstukken vind ik het altijd wel prettig als ik lokaal hetzelfde kan compileren als dat de build omgeving doet. Kan mij voorstellen dat je potentieel issues lokaal krijgt die op de echte omgeving er niet zijn en andersom.

Precies, daar ben ik ook bang voor.

[Bigs]

Zolang je met Framework 4.8.1 of .NET 5+ werkt zou het geen probleem moeten zijn. Met ouder spul is het ook werkbaar te maken maar dan loop je wel tegen beperkingen aan: https://learn.microsoft.c...-arm-devices?view=vs-2022

[Bigs]

SiErRa schreef op vrijdag 10 februari 2023 @ 10:42:
Los van Visual Studio licentie vraagstukken vind ik het altijd wel prettig als ik lokaal hetzelfde kan compileren als dat de build omgeving doet. Kan mij voorstellen dat je potentieel issues lokaal krijgt die op de echte omgeving er niet zijn en andersom.

.NET is een managed runtime en je code compiled naar IL. Voor standaard backend en Azure werk maakt het niet uit wat de onderliggende architectuur of besturingsysteem is.

[TweakerVincent]

Bigs schreef op vrijdag 10 februari 2023 @ 10:56:
[...]


.NET is een managed runtime en je code compiled naar IL. Voor standaard backend en Azure werk maakt het niet uit wat de onderliggende architectuur of besturingsysteem is.

Interessant! Ik kwam er net wel achter dat visual studio ARM net wat anders is. Copilot werkt bv niet. Maar zou wel super zijn als ik op mijn macbook kan developen.

[SiErRa]

Bigs schreef op vrijdag 10 februari 2023 @ 10:56:
[...]


.NET is een managed runtime en je code compiled naar IL. Voor standaard backend en Azure werk maakt het niet uit wat de onderliggende architectuur of besturingsysteem is.

Dat weet ik, en het zou niet voor moeten komen. Maar ik heb in de praktijk wel eens issues met .Net applicaties tussen verschillende versies van Windows gezien. Als er een compleet andere processor architectuur onder ligt is het risico nog wat groter, lijkt mij.

[AkakoMinami]

Ik zou gewoon op MacOs .NET gaan programmeren. Ikzelf heb sinds .NET Core 3.1 het altijd op een Mac gedaan en ook met Azure werk (in VS VCode) maakt het echt allemaal geen verschil.

Ik ben wel van Visual Studio for Mac naar Rider overgestapt voor het .NET werk, omdat die net wat uitgebreider is en ik gewoon prettiger vind.

Heb ook ARM Windows ernaast gedraaid even op mijn M1 Pro Macbook, maar liep tegen problemen aan met SQL Management Studio en SQL Server op Windows.
Terwijl SQL Edge met Azure Datastudio op MacOs als een zonnetje werkte.

[TweakerVincent]

AkakoMinami schreef op vrijdag 10 februari 2023 @ 11:58:
Ik zou gewoon op MacOs .NET gaan programmeren. Ikzelf heb sinds .NET Core 3.1 het altijd op een Mac gedaan en ook met Azure werk (in VS VCode) maakt het echt allemaal geen verschil.

Ik ben wel van Visual Studio for Mac naar Rider overgestapt voor het .NET werk, omdat die net wat uitgebreider is en ik gewoon prettiger vind.

Heb ook ARM Windows ernaast gedraaid even op mijn M1 Pro Macbook, maar liep tegen problemen aan met SQL Management Studio en SQL Server op Windows.
Terwijl SQL Edge met Azure Datastudio op MacOs als een zonnetje werkte.

Mss ook eens rider onderzoeken. Thanks iig! Denk dat ik met mijn macbook prima kan developen. Niet verwacht

[Falcon]

Inderdaad native op MacOS werken is prima te doen, mocht je in een team werken met zowel Windows als MacOS en je werkt met docker images... dan is het ook nog eens handig om een multi-architectural docker-image (docker buildx) te builden (async via ACR bijv.) van je Main branche.

Via Docker Compose kan je die dan aanroepen en heb je met je gehele team altijd de laatste versie te pakken.

Wij hebben kunnen op dit moment altijd lokaal een volledige omgeving optuigen (+ seeding) en daarna een nieuwe feature te gaan ontwikkelen en valideren. (shift-left gedachtegoed)

VSCode zou in principe ook voldoende moeten zijn, maar als je Studio gewend ben dan is Rider next best thing.

Happy programming!

[TweakerVincent]

Falcon schreef op maandag 20 februari 2023 @ 09:20:
Inderdaad native op MacOS werken is prima te doen, mocht je in een team werken met zowel Windows als MacOS en je werkt met docker images... dan is het ook nog eens handig om een multi-architectural docker-image (docker buildx) te builden (async via ACR bijv.) van je Main branche.

Via Docker Compose kan je die dan aanroepen en heb je met je gehele team altijd de laatste versie te pakken.

Wij hebben kunnen op dit moment altijd lokaal een volledige omgeving optuigen (+ seeding) en daarna een nieuwe feature te gaan ontwikkelen en valideren. (shift-left gedachtegoed)

VSCode zou in principe ook voldoende moeten zijn, maar als je Studio gewend ben dan is Rider next best thing.

Happy programming!

Dank! Ze gebruiken hier windows environment variables die uitgelezen worden in code. Volgens mij kan ik dat niet emuleren toch als ik native macos wil werken?

[Falcon]

TweakerVincent schreef op maandag 20 februari 2023 @ 18:10:
[...]


Dank! Ze gebruiken hier windows environment variables die uitgelezen worden in code. Volgens mij kan ik dat niet emuleren toch als ik native macos wil werken?

Voorbeeld? Want normaal gesproken geef je env vars mee aan .Net framework.

[TweakerVincent]

Falcon schreef op maandag 20 februari 2023 @ 20:14:
[...]


Voorbeeld? Want normaal gesproken geef je env vars mee aan .Net framework.

Ergens in een class worden letterlijk env windows variables uitgelezen. Dat kan ik nooit regelen in native macos toch?

[sig69]

TweakerVincent schreef op maandag 20 februari 2023 @ 23:04:
[...]


Ergens in een class worden letterlijk env windows variables uitgelezen. Dat kan ik nooit regelen in native macos toch?

Ze zullen waarschijnlijk niet bestaan dus dan hangt het er maar net vanaf hoe de code daar verder mee om gaat. Maar valt vast wat op te vinden.

[ Voor 46% gewijzigd door sig69 op 20-02-2023 23:28 ]

[Falcon]

TweakerVincent schreef op maandag 20 februari 2023 @ 23:04:
[...]


Ergens in een class worden letterlijk env windows variables uitgelezen. Dat kan ik nooit regelen in native macos toch?

Je gaf aan in je start post dat jullie met .Net werken. In .Net kan je env vars meegeven via een instelling in het project.

Maar niks staat je denk ik in de weg om deze env vars via een launcher mee te geven aan .Netcore. En dus kan dit ook op MacOS.

Het antwoord is dus niet ja/nee, heel misschien is er een kleine wijziging voor nodig om dit out-of-the-box compatble te maken voor mac gebruikers. Maar ik denk dat het team beslissing is, om multi-architecural te werken (x86/ARM).

https://learn.microsoft.c...net-environment-variables

[ Voor 3% gewijzigd door Falcon op 21-02-2023 06:56 ]