Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien
Toon posts:

[MVC4][TFS] NuGet packages met content items

Pagina: 1
Acties:

Verwijderd

Topicstarter
Ik maak al een tijdje gebruik van de NuGet package twitter.bootstrap.MVC4, zoals de naam aangeeft zorgt deze ervoor dat je in een MVC4 applicatie snel aan de gang kunt met een bootstrap basis. Daarnaast maak ik gebruik van TFS voor source control.

Sinds de bug gefixed is dat ie soms bij updates files niet wou overschrijven (nu vraagt ie het gewoon ipv het bestand over te slaan) werkt dit perfect en ben ik hier heel tevreden mee.

Echter nu heb ik een tijd terug het idee gekregen om een basis template zelf in een NuGet package te zetten, dit is mijn eigen aangepaste versie van het basis bootstrap pakket welke ik op mijn NAS zet zodat ik snel aan de gang kan met mijn eigen project. Dit werkt in principe ook prima.

Het probleem is dat alle bestanden in de NuGet Package direct in de solution terecht komen (gros staat in de content map in de package, zoals controllers, views, scripts, images etc.) en om die reden dus ook in TFS. Dat is an sich nog niet een probleem want ik kan na installatie gewoon gerust gaan customizen en het hele project uitbouwen. Zo heb ik een handvol projectjes gebouwd en dat werkt allemaal zoals verwacht.

Dan komen we aan bij het probleem: Ik heb in mijn basis template wat wijzigingen gemaakt om de nieuwste jquery enzo te gebruiken, plus wat bugfixes in de js en css. Nu wil ik die wijzigingen natuurlijk doorvoeren in al mijn projectjes, wat eenvoudig zou moeten gaan door een nieuwe versie van de package te maken en deze via NuGet te updaten.

Helaas zijn de bestanden gecustomized per project waardoor zomaar updaten niet gaat, dat was dus een fout.

Nu zit ik te denken naar een oplossing zodat ik niet nogmaals in deze valkuil loop.

Een oplossing zou zijn om binnen een project niet aan de bestanden van de NuGet package te komen. Zodoende kun je deze gewoon blind updaten zonder al te veel werk (hooguit wat BC fixen). Helaas staan de bestanden overal en nergens waardoor je snel per ongeluk een bestandje aanpast uit de package. Daarnaast komen alle bestanden in TFS te staan, terwijl ze nooit bijgewerkt zouden moeten worden. Dit geeft ook nog eens problemen wanneer ik wissel van PC (wat ik regelmatig doe). Wordt namelijk eerst de package geupdate en pas later de TFS zit ik gelijk met allemaal conflicten over bestanden die ik eigenlijk niet eens in TFS wil hebben.

Mijn vraag is dus:

Wat doe ik verkeerd? Is er een manier om die bestanden op een of andere manier te markeren zodat ik weet dat ze niet in TFS moeten en ik ze niet mag bewerken?
Zouden de bestanden niet overal en nergens door het project heen moeten staan? Dit heb ik overgenomen uit de twitter.bootstrap.MVC4 package, maar dat is wellicht niet goed, de vraag is alleen hoe dan wel?

Hopelijk kan iemand deze amateur op weg helpen. _/-\o_

  • eek
  • Registratie: Februari 2001
  • Laatst online: 06-04-2020

eek

@MagickNET

Om bestanden te ignoren zou je in de root van je project een .tfignore bestand kunnen plaatsen. Meer info is hier te vinden: MSDN: Add Files to the Server.

Maak je gebruik van dependancies in je eigen NuGet project om andere bestanden zoals jquery te includen? (http://docs.nuget.org/doc...e#Specifying_Dependencies)

[ Voor 6% gewijzigd door eek op 19-06-2013 21:25 ]

Skill is when luck becomes a habit.


Verwijderd

Topicstarter
Ja ik gebruik een .tfsignore om bijvoorbeeld de packages map te ignoren. Maar dan loop ik nog steeds het risico dat ik per ongeluk de bestanden uit de content map van het pakket ga wijzigen. Daarnaast is het niet echt heel praktisch om 100+ items in een .tfsignore te zetten. En moet ik handmatig als ik iets in mijn package wijzig ook de .tfsignore weer bijwerken. Dat lijkt me dus niet echt een handige oplossing.

Dependencies gebruik ik inderdaad, maar dat staat er verder los van. Daarmee kun je simpelweg ervoor zorgen dat wanneer je een bepaalde package nodig hebt deze ook daadwerkelijk beschikbaar is. Zo heb ik bijvoorbeeld een dependency naar webactivator (die ik anders toch wel gebruik). Maar zoals gezegd staat dat er los van, als je een dependency naar een package hebt waar ook weer content items in zitten wordt het probleem alleen maar erger.

  • R4gnax
  • Registratie: Maart 2009
  • Laatst online: 06-09 17:51
Verwijderd schreef op woensdag 19 juni 2013 @ 11:10:
Dan komen we aan bij het probleem: Ik heb in mijn basis template wat wijzigingen gemaakt om de nieuwste jquery enzo te gebruiken, plus wat bugfixes in de js en css. Nu wil ik die wijzigingen natuurlijk doorvoeren in al mijn projectjes, wat eenvoudig zou moeten gaan door een nieuwe versie van de package te maken en deze via NuGet te updaten.

Helaas zijn de bestanden gecustomized per project waardoor zomaar updaten niet gaat, dat was dus een fout.

Nu zit ik te denken naar een oplossing zodat ik niet nogmaals in deze valkuil loop.

Een oplossing zou zijn om binnen een project niet aan de bestanden van de NuGet package te komen. Zodoende kun je deze gewoon blind updaten zonder al te veel werk (hooguit wat BC fixen). Helaas staan de bestanden overal en nergens waardoor je snel per ongeluk een bestandje aanpast uit de package.
Herorganiseer je files zodat je dat probleem niet meer hebt? Ik gebruik zelf bijv. ook nooit meer de packaged versie van jquery of modernizr omdat deze direct in /Scripts/ gegooid worden, terwijl ik deze in /Scripts/lib/ wil hebben. Goed; je hebt wat meer werk om je eigen package structuur bij te houden, maar dat valt in het niet bij problemen die je zou krijgen met de gooi-alles-in-één-folder ratjetoe die er anders van komt.
Verwijderd schreef op woensdag 19 juni 2013 @ 11:10:
Daarnaast komen alle bestanden in TFS te staan, terwijl ze nooit bijgewerkt zouden moeten worden. Dit geeft ook nog eens problemen wanneer ik wissel van PC (wat ik regelmatig doe). Wordt namelijk eerst de package geupdate en pas later de TFS zit ik gelijk met allemaal conflicten over bestanden die ik eigenlijk niet eens in TFS wil hebben.
De in je project geinstalleerde bestanden wil je wèl in TFS hebben. De /packages/ folder op solution nivuau misschien niet, maar als je dat niet wilt zul je de package restore functionaliteit moeten gebruiken om de /packages/ folder weer correct terug te krijgen als je op een andere PC gaat builden. (Feitelijk krijg je dan een 'just-in-time download'.)

De situatie die je hier schetst mag je ook eens nader uitleggen, want het strookt totaal niet met hoe TFS en NuGet zich gedragen wanneer je een project uit TFS ophaalt of een package bijwerkt via de package manager en vervolgens je project incheckt.

Verwijderd

Topicstarter
Klopt voor jquery is dat een mogelijke oplossing. Maar hoe doe je dat bijvoorbeeld met controllers?

Packages folder inderdaad uitgesloten uit de TFS en de restore functionaliteit ingeschakeld. Dit lijkt me de juiste manier van werken? Waarom zou je bestanden uit de packages in TFS willen hebben? Het idee is toch dat NuGet de verantwoordelijkheid heeft die packages bij te werken en niet TFS? Als in mijn packages.config staat dat ik versie 2.0.1 van WebActivatorEx wil hebben dan bedoel ik daarmee te zeggen dat ik de bestanden uit die package wil hebben en niet iets anders. Nadeel van de packages in TFS is ook dat je veel zooi krijgt in je TFS log alleen maar omdat er een package is bijgewerkt. Voor packages die geen content items hebben werkt het dus perfect door de restore functionaliteit in te schakelen en de packages folder uit te sluiten van TFS.

Het punt is ook dat veel packages wel veel bestanden in de content folder hebben (zoals jquery zoals je noemt). Is dit dan echt fout?
R4gnax schreef op donderdag 20 juni 2013 @ 22:20:
De situatie die je hier schetst mag je ook eens nader uitleggen, want het strookt totaal niet met hoe TFS en NuGet zich gedragen wanneer je een project uit TFS ophaalt of een package bijwerkt via de package manager en vervolgens je project incheckt.
Wat wil je dat ik uitleg?

Wanneer je een project in TFS hebt en je een package bijwerkt waarin content items zitten dan geeft TFS bij het inchecken aan dat de bestanden gewijzigd zijn en wil deze meenemen. Het is daarbij lastig te zien welke zaken je zelf hebt gewijzigd en welke zaken simpelweg gewijzigd zijn omdat de package is bijgewerkt (ik let nu dus altijd goed op dat ik het bijwerken van package gerelateerde items los incheck zodat ik achteraf goed kan zien wat waarom gewijzigd is). In oudere versies waren er nogal wat bugs rondom het inchecken van items, TFS zag deze vaak als verwijderd en opnieuw toegevoegd wat problemen gaf, maar die bugs zijn inmiddels verholpen.

Hoe klopt wat ik zeg niet? Het is nogal kort door de bocht om te zeggen: Het klopt niet.

Kun je uitleggen waarom je de content items wel in TFS zou willen hebben maar de zaken in de packages folder juist niet? Het is het een of het ander lijkt me? Package restore gaat immers ook alle items in een package restoren en niet een deel.

[ Voor 57% gewijzigd door Verwijderd op 21-06-2013 15:17 ]


  • eek
  • Registratie: Februari 2001
  • Laatst online: 06-04-2020

eek

@MagickNET

Verwijderd schreef op donderdag 20 juni 2013 @ 12:53:
Ja ik gebruik een .tfsignore om bijvoorbeeld de packages map te ignoren. Maar dan loop ik nog steeds het risico dat ik per ongeluk de bestanden uit de content map van het pakket ga wijzigen. Daarnaast is het niet echt heel praktisch om 100+ items in een .tfsignore te zetten. En moet ik handmatig als ik iets in mijn package wijzig ook de .tfsignore weer bijwerken. Dat lijkt me dus niet echt een handige oplossing.
Je zou het aanmaken van een .tfsignore bestand ook kunnen automatiseren. Aan de hand van de inhoud van de packages map zou je met behulp van powershell een .tfsignore bestand kunnen genereren. Dan is het een stuk duidelijker welke bestanden van jezelf zijn.

Skill is when luck becomes a habit.


Verwijderd

Topicstarter
Dat is wel een heel goed idee., dat moet inderdaad helemaal niet zo lastig zijn en kan gewoon in het install script gedaan worden.

  • R4gnax
  • Registratie: Maart 2009
  • Laatst online: 06-09 17:51
Verwijderd schreef op vrijdag 21 juni 2013 @ 15:05:
Hoe klopt wat ik zeg niet? Het is nogal kort door de bocht om te zeggen: Het klopt niet.

Kun je uitleggen waarom je de content items wel in TFS zou willen hebben maar de zaken in de packages folder juist niet? Het is het een of het ander lijkt me? Package restore gaat immers ook alle items in een package restoren en niet een deel.
  1. Dit zijn geen conflicten. Conflicten krijg je als er een probleem is met het mergen van twee versies. Zolang niemand de content items die door NuGet in jouw project worden geinstalleerd met de hand heeft lopen bewerken, ga je daar geen last van hebben.
  2. De content items die aan je project toegevoegd worden wil je juist wel in TFS hebben, omdat deze niet door de package restore functionaliteit terug gezet worden. Enkel de package inhoud in de /packages/ folder wordt door package restore terug gezet.
Ik mag trouwens hopen dat je wel zo slim bent geweest om niet de /packages/ folder als solution folder toe te voegen aan je project en daarna direct daarin te gaan werken. Zo iemand ben ik ook nog eens tegen gekomen. Die begreep echt niet waar die mee bezig was.
Pagina: 1