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?

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.

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 ;-)

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

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.