Toon posts:

.NET ontwikkelen op ARM windows, te doen?

Pagina: 1
Acties:

Vraag


  • TweakerVincent
  • Registratie: April 2014
  • Laatst online: 19:02
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]

Alle reacties


  • ValHallASW
  • Registratie: Februari 2003
  • Niet online
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
  • Registratie: April 2014
  • Laatst online: 19:02
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
  • Registratie: Februari 2000
  • Laatst online: 16:37
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
  • Registratie: April 2014
  • Laatst online: 19:02
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
  • Registratie: Mei 2000
  • Niet online
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
  • Registratie: Mei 2000
  • Niet online
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
  • Registratie: April 2014
  • Laatst online: 19:02
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
  • Registratie: Februari 2000
  • Laatst online: 16:37
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
  • Registratie: December 2017
  • Laatst online: 30-03 14:11
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
  • Registratie: April 2014
  • Laatst online: 19:02
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
  • Registratie: Februari 2000
  • Laatst online: 16:10

Falcon

DevOps/Q.A. Engineer

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! :)

"We never grow up. We just learn how to act in public"


  • TweakerVincent
  • Registratie: April 2014
  • Laatst online: 19:02
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
  • Registratie: Februari 2000
  • Laatst online: 16:10

Falcon

DevOps/Q.A. Engineer

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.

"We never grow up. We just learn how to act in public"


  • TweakerVincent
  • Registratie: April 2014
  • Laatst online: 19:02
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
  • Registratie: Mei 2002
  • Nu online
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]

Roomba E5 te koop


  • Falcon
  • Registratie: Februari 2000
  • Laatst online: 16:10

Falcon

DevOps/Q.A. Engineer

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]

"We never grow up. We just learn how to act in public"

Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee