Al gezocht op stack overflow en github? Heb nooit met de .net omgeving gewerkt.quote:Op zondag 24 januari 2021 12:51 schreef Scooteraar het volgende:
Ik probeer mezelf te verdiepen in ASP.NET. Ik heb een nieuw project gemaakt op basis van .NET 5.0 en heb Entity Framework + SQLite geïnstalleerd.
Ik heb nu dotnet-ef nodig voor het maken van o.a. de migrations. Ik krijg alleen deze error:
Error NU1202 Package dotnet-ef 3.1.11 is not compatible with netcoreapp3.1 (.NETCoreApp,Version=v3.1). Package dotnet-ef 3.1.11 supports: netcoreapp3.1 (.NETCoreApp,Version=v3.1) / any API C:\Users\Scooteraar\source\repos\DatingApp\API\API.csproj
Ehh wat?
- Ik heb het target framework voor DatingApp.API verlaagd naar .NET 3.1
- Ik heb geprobeerd oudere (3.x) versies te installeren.
Wie is bekend met deze ellende?
Ik heb wel een beetje rond zitten kijken, maar nog geen oplossing gevonden. Het is ook niet heel belangrijk ofzo hoor, ik wilde gewoon wat experimenteren. Maar frustrerend wel.quote:Op zondag 24 januari 2021 13:12 schreef FlippingCoin het volgende:
[..]
Al gezocht op stack overflow en github? Heb nooit met de .net omgeving gewerkt.
Als ik dit zo lees lijkt het volgende een mogelijke oplossing te zijn:quote:Op zondag 24 januari 2021 12:51 schreef Scooteraar het volgende:
Error NU1202 Package dotnet-ef 3.1.11 is not compatible with netcoreapp3.1
dot net framework en dot net core zijn twee verschillende dingen. framework is zeg maar de windows extensie, core is zeg maar de multi-platform versie ervan. asp.net is net framework, aspnetcore is core framework. je dotnet-ef is zo te zien een net core library, maar je bent begonnen met een net framework applicatie. libraries voor net core werken vaak niet voor framework en vice versa. Praktisch alle libraries hebben wel versies compatibel met beide, maar je moet dus goed opletten welke je installeert. Soms zijn de libraries hernoemd waardoor het niet altijd even makkelijk is de compatibel evenknie te vinden, maar met google lukt dat altijd wel.quote:Op zondag 24 januari 2021 12:51 schreef Scooteraar het volgende:
Ik probeer mezelf te verdiepen in ASP.NET. Ik heb een nieuw project gemaakt op basis van .NET 5.0 en heb Entity Framework + SQLite geïnstalleerd.
Ik heb nu dotnet-ef nodig voor het maken van o.a. de migrations. Ik krijg alleen deze error:
Error NU1202 Package dotnet-ef 3.1.11 is not compatible with netcoreapp3.1 (.NETCoreApp,Version=v3.1). Package dotnet-ef 3.1.11 supports: netcoreapp3.1 (.NETCoreApp,Version=v3.1) / any API C:\Users\Scooteraar\source\repos\DatingApp\API\API.csproj
Ehh wat?
- Ik heb het target framework voor DatingApp.API verlaagd naar .NET 3.1
- Ik heb geprobeerd oudere (3.x) versies te installeren.
Wie is bekend met deze ellende?
Zeker, wat is je vraag?quote:
Sowieso zou ik heel erg uitkijken met externe repositories, er word soms veel te makkelijk vanuit gegaan dat het altijd maar beschikbaar en veilig is, letterlijk 1 regeltje in je nuget includes kunnen desastreuze gevolgen hebben.quote:Op zondag 24 januari 2021 11:43 schreef FlippingCoin het volgende:
Sommige bedrijven hebben zelfs een aantal dagen de documentatie offline gehaald voor een BLM statement.
Heb wel flink wat mensen uit o.a. Hong Kong flink pissed gezien daarover.
Maar goed dat zeg ik al veel langer, we zijn véél te afhankelijk van de amerikaanse nukken w.b. software.
Als je dit soort dingen leuk vind, kijk dan eens naar www.phaser.io zit ook heel veel in qua framework, echt heel tof hoe je bijvoorbeeld met 40 regels een compleet 3d spel kunt makenquote:Op vrijdag 22 januari 2021 19:13 schreef FlippingCoin het volgende:
[..]
Vandaag rond 11u begonnen en om 16u een korte presentatie over gegeven.
Ja voor chat dingen is het super handig, de tutorial is ook een chat maken.
En ik zag ook dat ze p2p ondersteunen nu maar daar geen tijd voor gehad om naar te kijken.
Wij gebruiken nu de volgende branch flow:quote:
Ja ik vond het ook echt bizar eigenlijk, een statement maken is een, maar er zijn wel gewoon bedrijven afhankelijk van die software... Maar goed, ken je afhankelijkheden inderdaad.quote:Op zondag 24 januari 2021 20:21 schreef raptorix het volgende:
[..]
Sowieso zou ik heel erg uitkijken met externe repositories, er word soms veel te makkelijk vanuit gegaan dat het altijd maar beschikbaar en veilig is, letterlijk 1 regeltje in je nuget includes kunnen desastreuze gevolgen hebben.
Het meest handige is al je gebruik maakt van GitFlow, is over het algemeen erg handig voor sprints van 2 weken, in het kort:quote:Op zondag 24 januari 2021 21:27 schreef FlippingCoin het volgende:
[..]
Wij gebruiken nu de volgende branch flow:
master -> feature -> test -> acceptance -> release
waarbij een feature van en naar master gaat, en vervolgens de features die goed bevonden zijn naar test dan wel acceptance of release cherry picked worden. Alleen dit geeft super veel merge conflicts omdat we een app van scratch maken en dus niet uit elkaars vaarwater kunnen blijven. Per sprint van 2 weken meerdere uren die aan merge conflicts + controleren of er niks mis is gegaan besteed worden.
Nu ben ik wat aan het kijken naar alternatieven maar ik vroeg mij af of hier iemand nog suggesties heeft.
en (hopelijk overbodig) werk zoveel mogelijk via interfaces , abstracts of header files of whatever je taal en je project ondersteunt, dat minimaliseert merge problemen als er iets aan de implementatiekant veranderd.quote:Op maandag 25 januari 2021 08:25 schreef raptorix het volgende:
[..]
Het meest handige is al je gebruik maakt van GitFlow, is over het algemeen erg handig voor sprints van 2 weken, in het kort:
-Iedereen werkt op Development
-Een uitzondering zijn feature branches, mag altijd, maar pull requests gaan altijd naar terug naar de development branch
-Wanneer je sprint ten einde loopt, dan word er een release branch gemaaakt van development
-Als uit testen bijvoorbeeld een bug word gevonden, dan word deze op de release branch gefixed (eventueel via een feature branch)
-Wanneer je klaar bent met testen en fixen, dan word de release branch terug gemerged naar Master en Dev, de release branch kun je sluiten, en een final build maak je van Master (dit zou in principe gelijk moeten zijn als je laatste release Branch!!!!
-Blijkt er na de release een probleem, dan maak je van de Master weer een Hotfix branch, en voer je het zelfde trucje uit, de fix merge je uiteraard ook terug naar development, dat wil je niet kwijt raken!
Kortom:
-Het grote voordeel is dat je team altijd op development kan blijven werken zonder dat er per ongeluk iets mee gereleased kan worden
-De release branch die je getest hebt, gaat naar productie, dus in principe is je laatste test versie altijd gelijk aan wat je naar productie release
-Je kunt ten alle tijden een hotfix maken op de Master branch zonder dat je bang hoeft te zijn zaken mee te releasen!!!!!
Belangrijk is om dus er voor te zorgen dat er branch policies op Master zitten, deze mogen alleen gepulled worden van een release of een hotfix branch!
https://nvie.com/posts/a-successful-git-branching-model/
Als tip, creeer met je team gewoon eens een sample projectje en ga het oefenen, je zult zien dat het erg overzichtelijk werkt
Nog een kleine tip, en dat is meer GIT algemeen, hou je pull requests klein, bij voorkeur gerelateerd aan 1 isssue, dat houd het overzichelijk en maakt de kans op merge problemen een stuk kleiner.
quote:Op maandag 25 januari 2021 08:25 schreef raptorix het volgende:
[..]
Het meest handige is al je gebruik maakt van GitFlow, is over het algemeen erg handig voor sprints van 2 weken, in het kort:
-Iedereen werkt op Development
-Een uitzondering zijn feature branches, mag altijd, maar pull requests gaan altijd naar terug naar de development branch
-Wanneer je sprint ten einde loopt, dan word er een release branch gemaaakt van development
-Als uit testen bijvoorbeeld een bug word gevonden, dan word deze op de release branch gefixed (eventueel via een feature branch)
-Wanneer je klaar bent met testen en fixen, dan word de release branch terug gemerged naar Master en Dev, de release branch kun je sluiten, en een final build maak je van Master (dit zou in principe gelijk moeten zijn als je laatste release Branch!!!!
-Blijkt er na de release een probleem, dan maak je van de Master weer een Hotfix branch, en voer je het zelfde trucje uit, de fix merge je uiteraard ook terug naar development, dat wil je niet kwijt raken!
Kortom:
-Het grote voordeel is dat je team altijd op development kan blijven werken zonder dat er per ongeluk iets mee gereleased kan worden
-De release branch die je getest hebt, gaat naar productie, dus in principe is je laatste test versie altijd gelijk aan wat je naar productie release
-Je kunt ten alle tijden een hotfix maken op de Master branch zonder dat je bang hoeft te zijn zaken mee te releasen!!!!!
Belangrijk is om dus er voor te zorgen dat er branch policies op Master zitten, deze mogen alleen gepulled worden van een release of een hotfix branch!
https://nvie.com/posts/a-successful-git-branching-model/
Als tip, creeer met je team gewoon eens een sample projectje en ga het oefenen, je zult zien dat het erg overzichtelijk werkt
Nog een kleine tip, en dat is meer GIT algemeen, hou je pull requests klein, bij voorkeur gerelateerd aan 1 isssue, dat houd het overzichelijk en maakt de kans op merge problemen een stuk kleiner.
Ik was nog vergeten te reageren sorry, ik ga van het weekend weer verder kijken; ik heb het er op mijn werk over gehad en ik ga een klein onderzoekje doen. Wij gebruiken nu gitflow maar ik stoor mij toch aan de vele conflicts, vooral omdat dit mergen te vaak bugs (her)introduceert.quote:Op maandag 25 januari 2021 09:01 schreef ralfie het volgende:
[..]
en (hopelijk overbodig) werk zoveel mogelijk via interfaces , abstracts of header files of whatever je taal en je project ondersteunt, dat minimaliseert merge problemen als er iets aan de implementatiekant veranderd.
Geen probleem, kan je wel zeggen dat een andere GIT strategie je merge problemen niet gaat oplossen, ik zou daarvoor eerder kijken of de commits kleiner kunnen en of je eventueel gebruik kunt maken van meer atomaire bestanden (bijvoorbeeld via includes of subclasses in losse files).quote:Op donderdag 28 januari 2021 21:42 schreef FlippingCoin het volgende:
[..]
[..]
Ik was nog vergeten te reageren sorry, ik ga van het weekend weer verder kijken; ik heb het er op mijn werk over gehad en ik ga een klein onderzoekje doen. Wij gebruiken nu gitflow maar ik stoor mij toch aan de vele conflicts, vooral omdat dit mergen te vaak bugs (her)introduceert.
Ik kwam in een talk wel de volgende quote tegen:quote:Op donderdag 28 januari 2021 21:45 schreef raptorix het volgende:
[..]
Geen probleem, kan je wel zeggen dat een andere GIT strategie je merge problemen niet gaat oplossen, ik zou daarvoor eerder kijken of de commits kleiner kunnen en of je eventueel gebruik kunt maken van meer atomaire bestanden (bijvoorbeeld via includes of subclasses in losse files).
Ik weet niet hoe groot je merge problemen zijn, maar ik had altijd tyfus hekel aan die editors waar je dat moet oplossen, meestal stelde ik gewoon mijn werk even veilig en deed even al mijn changes opnieuw op de laatste versie
En dat herken ik wel erg terug bij ons.quote:branching is an integration credit-card, you to pay that debt of sometime
Hm ja maar dat sluit niet aan bij het agile idee, iig niet bij ons, we kunnen niet zeggen oke deze tickets zijn niet af we wachten met een deploy tot de laatste feedback of wijzigingen ook verwerkt zijn; en daar wringt de schoen ook denk ik.quote:Op donderdag 28 januari 2021 22:09 schreef raptorix het volgende:
Het hele concept van Gitflow is dat je juist niet aan Cherrypicking doet, dan ga je inderdaad de problemen op je nek halen, Cherrypicking doe je binnen GitFlow hoogstens om bijvoorbeeld een hotfix te doen, of wellicht een fix op een release branch.
Tenzij ik jullie Git model niet helemaal goed begrijp waarbij je dus sprake hebt van een model waarbij je bepaalde delen van je repo's shared met andere projecten, dit laatste maakt het wel complexer, ik heb een aantal keren met dat soort systemen gewerkt en het vergt een behoorlijk goede architectuur, bij een grote reisorganisatie deded we dat door nuget packages te maken die als dependencies op andere projecten werden geladen, in de praktijk klinkt dat erg mooi, maar als je abstractie laag niet goed geregeld is, is het een recept voor hoofdpijn (zeker op projecten die niet elke spring worden geupdate )
Ja het hele idee van CI/CD is dat je ten alle tijden kunt deployen, alleen komt dat natuurlijk wel met een prijsquote:Op donderdag 28 januari 2021 22:14 schreef FlippingCoin het volgende:
[..]
Hm ja maar dat sluit niet aan bij het agile idee, iig niet bij ons, we kunnen niet zeggen oke deze tickets zijn niet af we wachten met een deploy tot de laatste feedback of wijzigingen ook verwerkt zijn; en daar wringt de schoen ook denk ik.
SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.Daarnaast bezig met de course over algoritmes en datastructuren maar niet heel veel tijd voor gehad, en ik ben bezig met een kleine tool in Java om meerdere dingen te copy pasten; en deze maak ik met RxJava, tijd niet meer met Java gewerkt dus het gaat niet heel soepel maar het is wel leuk om er weer eens mee bezig te zijnl.I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
quote:Op zondag 21 februari 2021 20:21 schreef FlippingCoin het volgende:
Ik ben bezig geweest met drie dingen buiten de normale werkzaamheden:
Voor de merge conflicts heb ik nu wat dingen besproken, en besloten het breder te trekken dan de branchin strategy en dat te onderzoeken: iig hier is de branching strategy zoals die nu is:SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.Daarnaast bezig met de course over algoritmes en datastructuren maar niet heel veel tijd voor gehad, en ik ben bezig met een kleine tool in Java om meerdere dingen te copy pasten; en deze maak ik met RxJava, tijd niet meer met Java gewerkt dus het gaat niet heel soepel maar het is wel leuk om er weer eens mee bezig te zijnl.
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |