Lsteinme

Also ich würds etwa so machen (in VB.net, lässt sich ja aber übersetzten): Dim Sourcefile As String = "FileX.txt" Dim dir As String = "DirectoryX" 'hier stehn nachher alle Namen von Bilddateien die da sein dürfen Dim gueltigeBilder As New List(Of String) For Each line As String In IO.File.ReadAllLines(Sourcefile) gueltigeBilder.Add(line) Next 'hier stehn die namen der Bilddateien die wirklich drin sind Dim Bildnamen As String() = IO.Directory.GetFiles(dir) For Each file As String In Bildnamen 'wenn der Filename nicht in zu den gültigen gehört, wird das File mit dem Namen gelöscht If Not gueltigeBilder.Contains(file) Then IO.File.Delete(file) End If Next Hoffe es ist verständlich was der Code genau tut.

funktioniert nicht, da sich beim SaveAs Befehl sowohl die Wordinstanz als auch das Programm aufhängt und nur noch auf ne Prozessterminierung über den Taskmanager reagiert.

Okay, da das Problem scheinbar nicht von meiner Applikation sondern von Word aus ging, hab beim Kollegen einfach mal das Worddokument sichtbar gemacht und versucht hier direkt von Hand zu speichern, mit Resultat das auch hier Word hängen geblieben ist, muss ich wohl so oder so ne andere Lösung finden.

Hallo, mein Problem ist folgendes, ich hab mir ein kleines Programm geschrieben was XML-Daten in ein HTML-Dokument parsed und dann mit einer Word-Application noch paar Feinheiten wie das Inhaltsverzeichnis das sicher per Klick aktualisiert einfügt. Bei einem Kollegen hängt sich das programm allerdings immer (bei einem bestimmten XML-File) in der Zeile worddoc.SaveAs("C:\Temp\TaR_Reporter\ExportFolder\Export.doc", FileFormat:=Word.WdSaveFormat) auf. (Bei mir funktioniert auch dieses File) Um das Problem schnell zu erledigen, der Kollege geht nächste Woche in Urlaub, wollte ich per Threads eine Art Überwachungssystem einbauen, welches wenn der Wordbearbeitungs-Thread zu lang brauch, diesen einfach abschießt, dann muss der Nutzer halt 4 klicks mehr machen. Das Problem ist nur, Thread.abort, scheint nicht zu funktionieren, zumindest bleibt das Wartefenster, welches anzeigt das Word im Hintergrund noch arbeitet, angezeigt. Das ganze ist etwas schwer zu Debuggen, weil ich den Fehler nicht/mehr nachgestellt bekomme. Gibt es für Threads etwas das dem Prozess.kill Kommando gleich kommt und den Thread auf jeden Fall sofort beendet?

klingt irgendwie wie ein Buddistischer Lehrspruch^^ ne aber Spass bei Seite, müsste dann nicht alles funkionieren wenn ich das tool als Admin starte? Ich hab in zwischen übrigens was entdeckt, vielleicht kann sich das ja wer erklären oder mir sagen wie ich den Compiler dazu zwinge es richtig zu machen. Wenn meine Zugriffe klappen, wird neben den Libs die ich über den Reference Reiter eingetragen habe noch die Assembly System.EnterpriseServices vom Compiler geladen. Das tut er aber leider nicht immer, bei denen bei (zum beispiel) die Datenbank funktionen nicht klappen wird diese Assembly nicht geladen. Das Problem daran ist, wenn ich die Assembly einfach in die References aufnehme hilft das nichts, da ich sie nie direkt im Code verwende, fliegt sie sofort wieder beim Compilieren raus. Ps, das gleiche Programm läd, bei denen bei denen es nicht klappt, einmal die Enterprise Lib(auf einer lokalen festplatte) und einmal nicht(auf dem übers Intranet erreichbaren Fileserver). Bei denen bei denen es klappt, läd der Compiler die Assembly auf beiden Pfaden.

Die SocketException wurde von der Singel-Instance Einstellung des Projektes ausgelöst. Ist aber scheinbar nur ein Teil eines Größeren Security Problems.

Okay, nach Tagen der suche nach den Problemen, die Socketexception war nur die Spitze des Eisberges, bin ich auf das wahre Problem gestoßen: Aus welchem Grund auch immer fehlen meiner Application MANCHMAL bestimmte Sicherheitsbefugnisse. Die Application ist unter .net 3.5 entwickelt. Wie "markiere" ich meine Application so das sie egal wer sie ausführt immer Vollständige Sicherheitsberechtigungen anfordert? Aus den Artikeln zum Thema Securitypermissions die ich per Google gefunden habe bin ich irgendwie nicht so ganz schlau geworden. PS: das This is a full trust application im Security reiter der Project-Propertys hatte keine Wirkung.

Das ist das Problem, ich habe keine Ahnung was diese Socketexception aus löst. Da ich bis dato keine Erfahrung in sachen Win7 und Fileserver(mit os Netapp) habe frage ich hier nach. Wenn ich den Haltepunkt auf die erste Methode meins Codes der aufgerufen werden sollte setzte(loadmethode der ersten GUI, wird dieser erst garnicht angesteuert, heißt die Exception kommt vor eintritt in meinen von mir/meinen Vorgängern geschrieben Code auf, also im autogenerierten.

ich kann erst garkeinen TryCatch block einbauen, weil der Fehler entsteht bevor mein eigentlicher Code gelesen wird. Edit: Doch, weis nicht wieso der 2te erschienen ist Im Errorstacktrace ist meine App nur einmal enthalten, und dieses Stelle ist leider auserhalb des Codes den ich direkt sehe: at PRIME.My.MyApplication.Main(String[] Args) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 81 oder weiß jemand wie ich an das file dort ran komme um einen Trycatch block um diese Zeile 81 zu setzten?

Hi, das problem zu beschreiben ist etwas schwierig, weil ich selbst nur schwammige Vermutungen hab wo es her kommt, und der Fehler nicht grade ausdruckstark ist. Mein Programm hat unter Windows XP immer super funktioniert, sowohl wenn ich es auf der Lokalen Festplatte gestartet habe, als auch wenn ich es von unserem Fileserver gestartet habe. Unter Windows 7 (64Bit) jedoch, funktioniert das Programm bei mir auf der Lokalen festplatte noch einwand frei. Versuche ich aber das Programm vom Fileserver zu starten, startet das Programm erst garnicht richtig und steigt direkt mit: "Programm funktioniert nicht mehr" aus. Als ich auf dem Server mal das Projekt mit dem Debugger starten wollte, kam der Debugger garnicht erst in meinen Code und stieg mehr oder minder direkt nach dem buildvorgang mit einer Socketexception aus. Leider sind die Details zur Exception recht mager, hier das was ich über view Detail, der Fehlermeldung erfahren konnte: Data: {System.Collections.ListDictionaryInternal}(Count=0) ErrorCode:10022 StackTrace: at System.Net.Sockets.Socket..ctor(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType) at System.Net.Sockets.TcpListener..ctor(IPAddress localaddr, Int32 port) at System.Runtime.Remoting.Channels.ExclusiveTcpListener..ctor(IPAddress localaddr, Int32 port) at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.SetupChannel() at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel..ctor(IDictionary properties, IServerChannelSinkProvider sinkProvider, IAuthorizeRemotingConnection authorizeCallback) at System.Runtime.Remoting.Channels.Tcp.TcpChannel..ctor(IDictionary properties, IClientChannelSinkProvider clientSinkProvider, IServerChannelSinkProvider serverSinkProvider) at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.RegisterChannel(Boolean SecureChannel) at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(String[] commandLine) at PRIME.My.MyApplication.Main(String[] Args) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 81 at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args) at System.Runtime.Hosting.ApplicationActivator.CreateInstance(ActivationContext activationContext, String[] activationCustomData) at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssemblyDebugInZone() at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart() Kennt jemand diese Art von Fehler, oder kann mir zumindest einen Denkanstroß geben in welcher Richtung ich nach dem Grund des Fehlers suchen muss? Ich bin aktuell ratlos, meine einzigen 2 Vermutungen wären das irgendwas im Buildscript für windows 7 anders sein müsste oder das der Server mit W7 bzw 64 Bit Betriebssystem nicht klar kommt. Gruß Lucas

Hi, das problem zu beschreiben ist etwas schwierig, weil ich selbst nur schwammige Vermutungen hab wo es her kommt, und der Fehler nicht grade ausdruckstark ist. Mein Programm hat unter Windows XP immer super funktioniert, sowohl wenn ich es auf der Lokalen Festplatte gestartet habe, als auch wenn ich es von unserem Fileserver gestartet habe. Unter Windows 7 (64Bit) jedoch, funktioniert das Programm bei mir auf der Lokalen festplatte noch einwand frei. Versuche ich aber das Programm vom Fileserver zu starten, startet das Programm erst garnicht richtig und steigt direkt mit: "Programm funktioniert nicht mehr" aus. Als ich auf dem Server mal das Projekt mit dem Debugger starten wollte, kam der Debugger garnicht erst in meinen Code und stieg mehr oder minder direkt nach dem buildvorgang mit einer Socketexception aus. Leider sind die Details zur Exception recht mager, hier das was ich über view Detail, der Fehlermeldung erfahren konnte: Data: {System.Collections.ListDictionaryInternal}(Count=0) ErrorCode:10022 StackTrace: at System.Net.Sockets.Socket..ctor(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType) at System.Net.Sockets.TcpListener..ctor(IPAddress localaddr, Int32 port) at System.Runtime.Remoting.Channels.ExclusiveTcpListener..ctor(IPAddress localaddr, Int32 port) at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.SetupChannel() at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel..ctor(IDictionary properties, IServerChannelSinkProvider sinkProvider, IAuthorizeRemotingConnection authorizeCallback) at System.Runtime.Remoting.Channels.Tcp.TcpChannel..ctor(IDictionary properties, IClientChannelSinkProvider clientSinkProvider, IServerChannelSinkProvider serverSinkProvider) at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.RegisterChannel(Boolean SecureChannel) at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(String[] commandLine) at PRIME.My.MyApplication.Main(String[] Args) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 81 at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args) at System.Runtime.Hosting.ApplicationActivator.CreateInstance(ActivationContext activationContext, String[] activationCustomData) at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssemblyDebugInZone() at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart() Kennt jemand diese Art von Fehler, oder kann mir zumindest einen Denkanstroß geben in welcher Richtung ich nach dem Grund des Fehlers suchen muss? Ich bin aktuell ratlos, meine einzigen 2 Vermutungen wären das irgendwas im Buildscript für windows 7 anders sein müsste oder das der Server mit W7 bzw 64 Bit Betriebssystem nicht klar kommt. Gruß Lucas

Noch nicht, wär aber mal nicht ganz praktisch^^

Dim s As String = "XPLACEFORSUMMARYX" Dim text As String = worddoc.Range.Text text = text.Replace(""c, "") text = text.Trim Dim startpos As Integer = text.IndexOf(s) war die lösung für das Indexproblem, wenn auch wahrscheinlich nicht die beste, da ich erst auslesen, dann suchen musste. schätze es müsste eigentlich auch ohne auslesen gehen.

hai, wenn ich worddoc.range.text sage und gehe mit dem Mauszeiger über den Text sehe ich die kreise, klick ich rein, sind sie nicht da. ich Checke grade noch was die berechnung hier durcheinander bringt, die "Kreise" warens nicht. Das sind scheinbar zeichen für "Hier steht kein Zeichen", was normalerweise nicht optisch interpretiert wird kopier mal "" und entfern die beiden Anführungsstriche, aber im Editor, da siehst du das Zeichen. EDIT: Halt sie warens doch Ich hatte beim späteren indexbestimmen noch ne alte ungefilterte Referenz drin

ok es scheint sich um den index des Buchstaben im fliestext zu handeln, ich habs jetzt einfach mal mit range.text.indexof versucht, das geht aber etwas in die hose, weil im range.text jede menge Schwarze ausgefüllte kreise drin sind, die nicht mit zur zeichenposition zählen wenn ich die Position an Word zurück gebe. Obendrein, kann ich die Punkte auch nicht einfach zählen und später abziehen, weil mein Visualstudio sich weigert das Zeichen irgendwie anzuzeigen, außer es ist in dem String...