| 

.NET C# Java Javascript Exception

4
Hallo

Wir haben hier ein Projekt, eine SLN, die hat 209 Projekte. Davon sind 21 WCF Services die auf verschiedenen Ports laufen. Jeder WCF Service, also quasi jedes Modul, hat eine eigene Konfigdatei. Die wird natürlich jedesmal, wenn geändert, beim starten kopiert.

Damit wir das Teil debuggen können gibt es eine kleine Console die die WCF Hosts startet. Funktionierte bislang einwandfrei.
Also etwa 21 mal sowas hier.

CoreServicesManager coreService = CoreServicesManager.Create();
coreService.Start();
Console.WriteLine("CoreService ...");

AlumniServicesManager alumniService = AlumniServicesManager.Create();
alumniService.Start();
Console.WriteLine("AlumniService ...");


Seit dem Update kommt immer wieder die Meldung von den Services das die entsprechende *.config Datei nicht gefunden werden kann. Man stoppt, startet nochmals, und wieder. Aber wahrscheinlich dann eine andere config. Das geht dann so eine weile bis VS endlich nachgibt.

Wenn man ins debug Verzeichnis schaut sind die config Dateien tatsächlich nicht vorhanden. Obwohl VS2012 erfolgreiches erstellen meldet.

Was uns auch aufgefallen ist. VS2012 löscht die config IMMER beim erstellen. Egal was definiert ist auf der config Datei.

Wir haben schon tausend Sachen probiert. Aber es will einfach nicht mehr. Mit VS2010 tratt das so gut wie nie auf. Mit VS2012 lässt sich fast nicht mehr arbeiten.

Ideen?
11.02.2013
GENiALi 2,5k 1 2 8
1
Also, ich weiß ja nicht, aber 209 Projekte in einer Solution? Ich denke, niemals wird an allen Projekten gearbeitet und daher gehören Projekte, die selten geändert werden, in eine eigene Solution. Die Hauptsolution mit den häufig geänderten Projekten, in welchem sehr viel gearbeitet wird, referenziert die benötigten DLL's. Das sollte die meisten Probleme beheben. Ansonsten, gerade in WCF Services, sind doch die IP Adressen usw. selten bekannt, können sich ändern. Also, Endpoints usw. zur Laufzeit erstellen! Weg mit 200 Config-Files!
Xantiva100 19.02.2013
Wird wahrscheinlich in die Richtung gehen. Den Ansatz haben wir auch schon verfolgt. Allerdings wegen Problemen immer wieder verworfen. Jetzt ist natürlich die Frage welches Problem einfacher zu beheben wäre. :-)
GENiALi 19.02.2013
1
Xantiva hat Recht. Wir hatten auch eine sehr große Solution. Nach einer Aufteilung und Referenzierung auf die weniger benötigten Projekte als Assembly (DLL) waren auch die Solutions um einiges besser zu pflegen. Ganz zu schweigen von der Kompiliergeschwindigkeit. Endpunkte für Services und sonstige Konfiguration machen wir grundsätzlich zur Laufzeit und nicht über die AppConfigs. Welche Probleme hattet ihr denn?
JEwen 20.02.2013
4 Antworten
1
Es hat zwar nicht direkt mit dem Problem zu tun, aber ich empfehle euch, dass ihr euch mal an MS wendet.
Wir haben eine ähnlich große Solution und sind auch auf tolle Phänomene gestossen: VS markiert plötzlich Kommentare als Fehlerhafte Codezeilen, kennt plötzlich keine Integer mehr und bricht plötzlich (ohne erkennbaren Grund) beim Kompilieren ab oder erstellt Projekte mehrmals.
Grund dazu (lt. MS) liegt in der Größe der Solution. VS 2010 und VS2012 sind "nur" 32bit-Programme. Daher nutzen ja pauschal nur einen Teil des gesamten Arbeitsspeichers - also nur den Teil, den das Betriebssystem für 32bit Prozesse gesamt(!) freigibt. Selbst unter 64bit-System sind es nur (lasst mich lügen) epps um die 2GB (oder so).
Mit unserer Solution sind wir dabei an die Grenze gestossen.
Fazit: Solution neu aufgebaut und auf 2 verteilt - dadurch sind nur noch ca. 100 Projekt drin und der Speicherbedarf geht runter: siehe da es kommen wieder ordentliche Ergebnisse.

Also kann sein, dass es daran liegt.
19.02.2013
daWastl 277 1 7
Das mit dem Speicher könnte durchaus hinkommen. Ich habe VS2012 schon des öffteren über 1.5GB angetroffen.
GENiALi 19.02.2013
0
Wahrscheinlich wurden bei den *.config-Dateien schon gecheckt ob diese auch bei der Buildeinstellungen der *.config-Dateien auch richtig als Inhalt angegeben worden ist.

Da ihr bei 209 Projekten in einer SLN habt, was ich ja nicht mehr als ein "kleines" Projekt im Hoppybereich bezeichne, gehe ich mal stark davon aus, dass ihr irgendeine Form von MSDN-Subscription habt und da natürlich auch Suport von MS inklusive habt. Auch eine Anfrage und/oder Recherche auf connect.microsoft.com würde ich empfehlen. Dass ihr da einen nicht ganz alltäglichen Bug gefunden habt, halte ich für diese Anzahl an Projekten und WCF-Service für schon eher wahrscheinlich.

PS: Dass ihr "schon tausend Sachen probiert" habt, nenne ich verschlimmbessern ;-)
12.02.2013
Stelzi79 44 1
Schlimmer wurde es nicht. Besser allerdings auch nicht.
GENiALi 12.02.2013
0
Hallo,

kann es sein, dass beim Build die "falsche" .config genommen wird?
Es besteht die Möglichkeit für eine Build im Releasemodus eine andere .config zu nehmen als bspw. beim Build im Debugmodus.

Unterhalb der *.config sollte es dann folgende Struktur geben.

+ web.config
---web.debug.config
---web.release.config
12.02.2013
lbm1305 849 1 8
Trifft das auch zu wenn man sowas hier hat?
modul1.config
modul2.config
modul3.config
...

Wir haben einen eigenen config Loader. Das Problem scheint nur zu sein das die config nicht in jedemfall kopiert wird.
GENiALi 12.02.2013
Schwer zusagen, wenn man die Struktur nicht kennt.
lbm1305 12.02.2013
Die Zuweisung, welche *.config beim Erstellen in einem bestimmten Modus genommen wird, kannst du in den Solutioneigenschaften => Konfigurationseigenschaften einstellen.
lbm1305 12.02.2013
Dort sehe ich aber nur ob debug oder release ist. Oder? Da unsere Configs aber nur modul1.config heissen ...
GENiALi 12.02.2013
1
Hmmm...dann sollten auch nur diese genommen werden. :-/
lbm1305 12.02.2013
0
Da Du von einem Update sprichst, nehme ich mal an, dass Ihr die Solution samt Projekte von VS2012 habt migrieren lassen? Auch wenn es nur ein weiterer Versuch ist, aber legt doch mal ein Projekt mit VS2012 von Scratch an und schaut, ob das Problem besteht. Ich habe von den ein oder anderen Problemchen des Upgrade-Wizards gelesen, vlt. gehört Euer Problem auch dazu. Wenn das hilft, sollte ein Diff der csproj-Files das Problem zu Tage fördern.

Als BruteForce Lösung könntet Ihr versuchen, die Kopieraktion erstmal manuell in die fraglichen msbuild-Skripte (.csproj Files) aufnehmen. Das verschafft Euch zumindest weitere (stressreduzierte) Recherchezeit.
12.02.2013
ffordermaier 8,4k 3 9
Autsch...
Schlage das mal meinem Chef vor. Scheint wohl kein einfaches Problem zu sein. :-/
GENiALi 12.02.2013

Stelle deine Visual-studio-2012-Frage jetzt!