vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
Zippen wie die Profis!  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2024
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

VB.NET - Fortgeschrittene
INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: Schudi
Datum: 02.06.17 11:36

Ich habe ein Programm, dass im Ordner \Programme\MeineFirma\Programmname installiert wird.

Dieses Programm speichert seine Einstellungen beim Programmende in eine ini-Datei im Programmverzeichnis.

Das klappt unter Windows10 pro Creators Update aber nur wenn ich das Programm "als Admin" ausführe. Andernfalls kommt die Meldung "Zugriff verweigert".

Das verrückte ist, dass ich sogar als Nutzer mit Adminrechten angemeldet bin.

Die ini-Datei wird erzeugt, indem ich ein Dataset mit WriteXML schreibe

mySettingsDs.WriteXml(Path.Combine(Application.StartupPath, "Settings.ini"))
Wird die Datei nicht im Programmverzeichnis sondern z.B. in C:\Test erzeugt, ist alles ok. Dann kommt keine Meldung.

Benötige ich zum Schreiben in Unterordner von "\Programme" tatsächlich Admin-Rechte? Und wenn ja, wie kann ich diese erlangen?

P.S.: Wenn ich im Explorer einen Rechtsklick im geöffneten Programmordner mache, dann bietet er mir dort auch nur "neuer Ordner" an. Also scheint das Anlegen von Dateien dort tatsächlich geblockt zu sein...
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: effeff
Datum: 06.06.17 21:30

Die Sicherheitsphilosophie von Windows sagt aus, dass der normale Nutzer nur in bestimmten Verzeichnissen schreiben darf. Das Programmverzeichnis ist genauso wie z. B. das Windows-Verzeichnis tabu. Ob Du nun als Nutzer mit Admin-Rechten ausgestattet sein willst oder nicht, ist dabei völlig egal. Volle Admin-Rechte erhältst Du erst mit "Als Administrator ausführen". Deine ini-Datei, die anscheinend ja eine XML-Datei ist, gehört eindeutig ins AppData-Verzeichnis. Hier werden Einstellungsdateien für Programme abgespeichert.

Den Pfad zum AppData-Verzeichnis kannst Du so abfragen:

Environment.GetEnvironmentVariable("appdata")
Dort estellst Du beim Zugriff ein Unterverzeichnis für Dein Verzeichnis, in welches Du dann Deine XML speichern kannst:

        Dim Datenverzeichnis As String = Environment.GetEnvironmentVariable( _
          "appdata")
 
        Dim MeinVerzeichnis As String = "MeinProgrammname"
 
        System.IO.Directory.CreateDirectory(Datenverzeichnis & "\" & _
          MeinVerzeichnis)

EALA FREYA FRESENA

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: Franki
Datum: 07.06.17 02:31

Hallo,

eine richtige Antwort hast du ja schon bekommen, aber schau dir doch mal zur Ergänzung warum und wieso das alles so ist etwas zum Stichwort UAC bzw. Benutzerkontensteuerung zu neueren Windows Versionen an. Das gilt nicht nur für Win 10 sondern auch schon seit Vista, bzw. noch früher bei XP über W2K bis runter zu NT 3.5 wenn man es "richtig" konfiguriert hatte.

Ein Nutzer der sich mit Admin Rechten am Rechner anmeldet hat nicht automatisch die entsprechenden Rechte wenn er ein Programm ausführt. Die Anmeldung besagt lediglich, dass er sich bei Bedarf die notwendigen Rechte verschaffen kann ohne erneut seine Zugangsdaten eingeben zu müssen. Da reicht dann eine entsprechende Bestätigung per Mausklick (Oder Tastatur). Aber diese Bestätigung ist absolut notwendig ohne geht gar nichts.

Und gewisse Verzeichnisse sind halt für Schreibrechte erst mal tabu, dass muß man einfach respektieren, es bringt nichts dagegen ankämpfen zu wollen, besser man nutzt die von Windows vorgegebenen Verzeichnisse (Stichwort SpecialFolders) für solche Sachen. Dann ist man auf der sicheren Seite und hat weniger Probleme grade auch dann wenn man eine Software schreibt die auf verschiedenen BS laufen soll. (Da untrescheiden sich die Namen nämlich oft)

Gruß
Frank
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: Schudi
Datum: 10.06.17 18:41

Ok, danke. Dann lege ich die Datei am Besten dort an.

Bislang hatte ich es immer gerne dass alle Dateien des Programms an einer Stelle zu finden sind. Aber ok ... bin ja lernfähig.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: Schudi
Datum: 10.06.17 18:42

Ok, danke.

Ich verstehe und werde mich dran halten. Macht ja irgendwo auch Sinn.

Bislang war ich halt ein Verfechter der These, dass es am Besten sei alle Dateien einer Anwendung an einer Stelle zusammen zu halten. Aber ich bin ja lernfähig.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: Franki
Datum: 11.06.17 04:06

Hallo,

ich sag mal so, dass es immer noch sinnvoll ist alle Dateien einer Anwendung an einer Stelle haben zu wollen. Windows macht uns da halt einen Strich durch die Rechnung.

Aber uns ist ja bekannt wo die Dateien liegen, man kann sie einsammeln und auch auf einem anderen Rechner wieder verteilen, wenn man seine Anwendung komplett "mitnehmen" möchte. Die "SpecialFolders" sind dabei sogar hilfreich wenn es sich bei einem Wechsel um verschiedene Betriebssystem handelt.

Ich mache das so, dass ich z.B. bei einer Datensicherung aus der eigenen Anwendung die verteilten Daten wie ini usw. einsammle, in eine Zip verpacke und jederzeit wieder verteilen kann an die richtige Stelle.

Die "eine Stelle" gilt nicht mehr, man muß nur wissen wo was hin gehört.

Gruß
Frank
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: Schudi
Datum: 11.06.17 07:47

Ja, da hast Du wohl recht.

Werde solche INI-Dateien künftig auch nach AppData bzw. einen eigenen Unterordner von AppData\Roaming legen.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Ergänzender Hinweis 
Autor: Manfred X
Datum: 11.06.17 09:28

Hallo!

Für das Speichern von Programmeinstellungen (Settings) gibt es im Framework einen
speziellen "Mechanismus" (Klassen) der z.B. auch direkte Datenbindung
ermöglicht und die Dateien/Einstellungen in den vorgesehenen Ordnern
installiert/verwaltet.

Dabei ist unterscheidbar, ob Einstellungen für alle Programm-Nutzer gelten
oder ob es user-spezifische Werte gibt.

Beitrag wurde zuletzt am 11.06.17 um 09:32:00 editiert.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Ergänzender Hinweis 
Autor: Schudi
Datum: 15.06.17 06:43

Ich denke Du meinst die Möglichkeit in den Projekt-Eigenschaften unter "Einstellungen" diverse Eigenschafteneinstellungen für "Benutzer" oder "Anwendung" zu hinterlegen....

Vermutlich sollte man diese Möglichkeit dann einer eigenen INI-Datei vorziehen...


Allerdings habe ich gelesen, dass diese Einstellungen bei einem späteren Update des Projektes nicht übernommen werden, was fatal wäre. Auch wenn es nur um 4 Werte geht, soll der Anwender diese auch nach einem Update nicht immer wieder neu eingeben müssen.

Beitrag wurde zuletzt am 15.06.17 um 06:46:50 editiert.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Ergänzender Hinweis 
Autor: Manfred X
Datum: 15.06.17 11:05

Hallo!

Schau mal hier rein:
https://stackoverflow.com/questions/534261/how-do-you-keep-user-config-settings-across-different-assembly-versions-in-net
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: effeff
Datum: 15.06.17 16:01

Zitat:

ich sag mal so, dass es immer noch sinnvoll ist alle Dateien einer Anwendung an einer Stelle haben zu wollen. Windows macht uns da halt einen Strich durch die Rechnung.


Der Meinung bin ich nicht. Ausgerechnet in der heutigen Zeit halte ich es für sehr sinnvoll, Anwendung und Daten getrennt zu halten, um mit unterschiedlichen Sicherheitskriterien arbeiten zu können. Das ist eine Sache, die Windows erst sehr spät von richtigen Betriebssystem gelernt hat...

Im Ernst: Das hat was damit zu tun, ein System zu härten und es Angreifern schwieriger zu machen. Hast Du schon mal überlegt, wie einfach ein solcher es hätte, würdest Du auf ein Programmverzeichnis Schreibrechte für einen User setzen, dort Schadsoftware zu installieren?

Zitat:

Die "eine Stelle" gilt nicht mehr, man muß nur wissen wo was hin gehört.


Sie hätte eigentlich nie gelten dürfen; Da haben Bill und Co. seit DOS-Zeiten lange Schindluder getrieben. Damals durften noch ini-Dateien sogar mit ins Windows-Verzeichnis!

EALA FREYA FRESENA

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: Franki
Datum: 16.06.17 01:34

Hallo effeff

Sorry, vielleicht habe ich mich falsch ausgedrückt.

Zitat:

Zitat:

ich sag mal so, dass es immer noch sinnvoll ist alle
Dateien einer Anwendung an einer Stelle haben zu wollen.
Windows macht uns da halt einen Strich durch die
Rechnung.


Zitat:


Der Meinung bin ich nicht. Ausgerechnet in der heutigen Zeit
halte ich es für sehr sinnvoll, Anwendung und Daten getrennt
zu halten, um mit unterschiedlichen Sicherheitskriterien
arbeiten zu können. Das ist eine Sache, die Windows erst sehr
spät von richtigen Betriebssystem gelernt hat... .


Hier ist der Punkt an dem ich mich falsch ausgedrückt habe.
Ich befürworte, dass das so wie früher nicht mehr möglich ist ausdrücklich. Anwendung und Daten müssen getrennt sein, das ist gar keine Frage.

Was aber für den User bzw. auch Entwickler / Admin usw. so bequem wie möglich sein sollte ist z.B. ein Umzug der eigenen Anwendung auf einen anderen Rechner. Installation der Anwendung kein Thema, aber die Arbeit fängt danach an die 1:1 so zu haben wie vorher. Also die ganzen Möglichkeiten der Anpassung von Einstellungen usw. sind für die meisten User sehr mühsam bzw. je nach Anwendug fast unmöglich.

Zitat:

Die "eine Stelle" gilt nicht mehr, man muß
nur wissen wo was hin gehört.


Zitat:


Sie hätte eigentlich nie gelten dürfen; Da haben Bill und Co.
seit DOS-Zeiten lange Schindluder getrieben. Damals durften
noch ini-Dateien sogar mit ins Windows-Verzeichnis!


Richtig, deswegen muss man heutzutage als Entwickler dem User (oder sich selbst als Admin) den Komfort bieten solche Wünsche regeln zu können. Alles in die Cloud zu packen ist eine Möglichkeit, aber das ist aus Sicherheitsbedenken bei vielen meiner Kunden nicht möglich bzw. wird nicht akzeptiert.

Deswegen baue ich mir bei einigen meiner Anwendung halt den Komfort ein, dass das für den User über ein kleines Feature geht, alles eingesammelt wird von den verschiedensten Stellen und nachher wieder richtig verteilt wird.

INI Dateien sind ja nur ein kleiner Bereich, es gibt ja noch andere Stellen wie z.B. Registry usw. wo man einsammeln und wieder verteilen muss.

Ich habe schon Anwendungen gesehen wo der Entwickler wenn eine Datenbank sowieso vorhanden war jeden Sch... der da eigentlich nicht rein gehört dort in X Tabellen gespeichert hat. Nach dem Motto: Warum brauche ich Ini, XML, Registry wenn ich eine DB habe auf die sowieso zugriffen werden muss?

Gruß
Frank
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: Schudi
Datum: 16.06.17 06:31

1) Also ich mache das jetzt so, bzw. habe es wie vorgeschlagen gelöst, dass ich die Einstellungen (Benutzer-Settings) in den Projekt-Eigenschaften nutze, wodurch die von Windows vorgesehenen Dateien in AppData automatisch genutzt werden.


2) Die Sache mit dem "Einsammeln per Knopfdruck" finde ich im Bezug auf den Umzug der Software auf einen neuen Rechner oder auch die Datensicherung gut. Einstellungsdateien zusätzlich in die Cloud zu speichern finde ich nicht sinnvoll. Außerdem wird das von den meisten meiner Kunden abgelehnt.

Zitat:

INI Dateien sind ja nur ein kleiner Bereich, es gibt ja noch andere Stellen wie z.B. Registry usw. wo man einsammeln und wieder verteilen muss.


Womit ich dann gleich mal zu etwas grundsätzlichem komme...

Die Programmeinstellungen sollen nach AppData ... ok, kapiert

Die Programmdatenbanken sollen ja nach Möglichkeit auch getrennt gehalten werden. (Bislang legen wir diese in einen separaten Parallel-Ordner getrennt von den Programmen aber unter einem Ober-Ordner zusammen gefasst.)

Was bzw. welche Einstellungen sollten denn überhaupt noch von Programmen in der Registry abgelegt werden?
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: Manfred X
Datum: 16.06.17 08:23

Hallo!

Ich nutze die Registry bei Net-Anwendungen nicht.
Man kann zu diesem Thema unterschiedliche Argumente finden, z.B.
http://blog.bigbasti.com/vb-net-einstellungen-in-der-windows-registry-speichern/
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: effeff
Datum: 16.06.17 09:25

Zitat:

Was aber für den User bzw. auch Entwickler / Admin usw. so bequem wie möglich sein sollte ist z.B. ein Umzug der eigenen Anwendung auf einen anderen Rechner. Installation der Anwendung kein Thema, aber die Arbeit fängt danach an die 1:1 so zu haben wie vorher. Also die ganzen Möglichkeiten der Anpassung von Einstellungen usw. sind für die meisten User sehr mühsam bzw. je nach Anwendug fast unmöglich.


Das ist relativ einfach; Man hält die Daten und Einstellungen zentral, z. B. auf einem Server. Wenn eine Datenbank dahinter hängt, würde ich die sowieso immer grundsätzlich auf einen Server legen. Von der Philosophie her gehe ich davon aus, dass Serverdaten regelmäßig gesichert werden, während der Arbeitsplatz eines Benutzers nur grundsätzlich aufgesetzt wird und bei Problemen z. B. mittels Paketverwaltung neu aufgesetzt wird.

Zitat:

Deswegen baue ich mir bei einigen meiner Anwendung halt den Komfort ein, dass das für den User über ein kleines Feature geht, alles eingesammelt wird von den verschiedensten Stellen und nachher wieder richtig verteilt wird.


Die Probleme habe ich nicht; Siehe erste Antwort.

Zitat:

INI Dateien sind ja nur ein kleiner Bereich, es gibt ja noch andere Stellen wie z.B. Registry usw. wo man einsammeln und wieder verteilen muss.


Da ich diese Daten ebenfalls in Datenbanktabellen zu schreiben pflege, habe ich auch diese Last nicht. Ich benutze Windows zwangsläufig beruflich, privat aber fast ausschließlich Linux. Linux kennt keine Registry. Von daher verzichte ich eh darauf, die Registry zu benutzen.

Zitat:

Ich habe schon Anwendungen gesehen wo der Entwickler wenn eine Datenbank sowieso vorhanden war jeden Sch... der da eigentlich nicht rein gehört dort in X Tabellen gespeichert hat. Nach dem Motto: Warum brauche ich Ini, XML, Registry wenn ich eine DB habe auf die sowieso zugriffen werden muss?


Nun, ich fürchte, ich bin jemand, der lieber die Datenbank benutzt, weil ich dann schlank und ohne Schnörkel meine Anwendungen verteilen kann. Das vereinfacht die Installation und bei einem Rechnercrash sind die Daten nicht verloren. Allerdings behaupte ich auch, dass das, was ich dort speichere, hinein gehört und nicht zur Kategorie "Sch..." gehört...

Allerdings rede ich hier nicht von Einzelplatzanwendungen. Ich muss gewährleisten, dass meine User bundesweit an jedwedem Arbeitsplatz sitzen und arbeiten können. Bei einer Einzelplatzanwendung würde ich so vorgehen wie Du und eine Datensicherungsfunktion einbauen. Das reicht dann dort.

Und BTW: Cloud benutze ich gar nicht.

EALA FREYA FRESENA

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: Manfred X
Datum: 16.06.17 10:42

Hallo!

Es versteht sich, daß die Beantwortung solcher Fragen immer
in enger Abhängigkeit vom konkreten Anwendungsfall erfolgt.

Prinzipiell einzubeziehen sind dabei Gesichtspunkte wie
1.) - der erforderliche Grad an Dauerhaftigkeit der Speicherung
2.) - die Selektivität der Daten-Geltung (für Benutzergruppen, für Anwendungsgruppen)
3.) - der Sicherheitsbedarf (technische Ausfallsicherheit, automatische Backups)
4.) - rechtliche Regelungen z.B. Datenschutz oder Haftung/Gewährleistung

zu 1.)
Der niedrigste Grad an Dauerhaftigkeit betrifft temporäre Daten, die nur
während einer "Session" crash-sicher zu speichern sind (Restart-Fähigkeit)
und die beim regulären Beendigen eines Programms gelöscht werden.
Solche Angaben können aber nur dann in einer lokalen Crash-Datei abgelegt werden,
wenn sie nicht sicherheitsrelevant gemäß 5.) sind.
Andere temporäre Daten müssen vorsorglich in einer geschützten Datenbank eingetragen
werden.

zu 2.)
Es ist zu unterscheiden, ob Einstellungen für individuelle User gelten oder
ob der Zugriff auf gruppenbezogene Einstellungs-Profile erfolgt.
Zu beachten ist auch, wer die Berechtigung besitzt, Profile zu modifizieren.
Gruppenbezogene Settings sollten deshalb in speziellen Settings-DBs abgelegt werden.

3.)
Bei hohen Anforderungen an die Ausfallsicherheit und die Dauerhaftigkeit der
Daten, stehen Überlegungen im Vordergrund, wie gewährleistet werden kann, daß die
verwendete Hard- und Software stets auf dem neuesten Stand der Technik ist.

Im Rahmen der Speicherung von Programm-Einstellungen ist zu beachten, daß eine
strikte sachlogische Trennung von Settings-Angaben und Anwendungsdaten erfolgt.
Suchschlüssel, Abfrageparameter o.ä. sollten nicht als Einstellungen gespeichert,
sondern in den zugrundeliegenden DBs abgelegt werden.

4.)
Für das Speichern von Einstellungen relevant, wenn es sich um geschützte
Informationen handelt. Es versteht sich, daß Passworte, abgefragte Daten o.ä.
nicht als "Settings" zwischen-gespeichert werden dürfen.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: Franki
Datum: 17.06.17 03:04

Hallo effeff
Ok, dann sind wir uns ja einig, aber ich habe eine gemischte Anforderung, siehe unten...

Zitat:


Nun, ich fürchte, ich bin jemand, der lieber die Datenbank
benutzt, weil ich dann schlank und ohne Schnörkel meine
Anwendungen verteilen kann. Das vereinfacht die Installation
und bei einem Rechnercrash sind die Daten nicht verloren.
Allerdings behaupte ich auch, dass das, was ich dort
speichere, hinein gehört...


Ja, aber das setzt ja voraus, dass die DB die DB auch jederzeit erreichbar ist wie auch immer (Netzwerk, Internet usw.) Und genau hier liegt mein Problem...

Zitat:


Allerdings rede ich hier nicht von Einzelplatzanwendungen.
Ich muss gewährleisten, dass meine User bundesweit an
jedwedem Arbeitsplatz sitzen und arbeiten können. Bei einer
Einzelplatzanwendung würde ich so vorgehen wie Du und eine
Datensicherungsfunktion einbauen. Das reicht dann dort.


Hast du einen User hier in der Gegend?
Fakt ist ja, dass wenn jemand mit einem Notebook unterwegs ist und keinen (oder nur sehr langsamen) Internetzugang hat quasi einen Einzelplatzrechner hat, aber trotzdem damit z.B. im Außendienst arbeiten muss.

Da führt kein Weg daran vorbei anfallende Daten lokal auf dem Notebook zu speichern und dann später in die richtige DB zu übertragen. Gleiches gilt auch umgekehrt vor dem Besuch beim Kunden hier in der Gegend.

Aber das Thema würde jetzt zu komplex werden und auch etwas OT, das es sich ja nur um ini Dateien handelt. DB Abgleich usw. muss ich mit eigenen Nummernkreisen für User machen usw. usw.

Tja hier im ländlichen Gebiet ist das halt so eine Sache, es ist einerseits nervig, aber andererseits kann ich damit gut Geld verdienen indem ich Individuallösungen anbiete weil die Standardanwendungen nicht wirklich funktionieren ohne permanente Erreichbarkeit eines Servers oder einer Datenbank die nur in einem Netzwerk verfügbar ist.

Gruß
Frank
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: effeff
Datum: 17.06.17 15:51

Zitat:

Hast du einen User hier in der Gegend?
Fakt ist ja, dass wenn jemand mit einem Notebook unterwegs ist und keinen (oder nur sehr langsamen) Internetzugang hat quasi einen Einzelplatzrechner hat, aber trotzdem damit z.B. im Außendienst arbeiten muss.


Nicht, dass wir da aneinander vorbei schreiben...

Meine Nutzer befinden sich normalerweise innerhalb eines bundesweiten Datennetzes; Nicht im Internet...

Ansonsten bin ich der Meinung: Es spricht nichts dagegen, wenn der Server nicht erreichbar ist, mit einer temporären Einstellungsdatei zu arbeiten und diese Daten dann wieder, wenn der Server dann erreichbar ist, abzugleichen.

EALA FREYA FRESENA

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: INI.Datei im Programmverzeichnis nur als Admin möglich? 
Autor: Franki
Datum: 18.06.17 00:21

Hallo effeff

Zitat:


Meine Nutzer befinden sich normalerweise innerhalb eines
bundesweiten Datennetzes; Nicht im Internet...


Ok, das ist ein ganz anderes Thema...

Zitat:


Ansonsten bin ich der Meinung: Es spricht nichts dagegen,
wenn der Server nicht erreichbar ist, mit einer temporären
Einstellungsdatei zu arbeiten und diese Daten dann wieder,
wenn der Server dann erreichbar ist,
abzugleichen.


Und genau so mache ich es ja auch. Und um beim Thema ini zu bleiben, oder des Einsammelvorgangs und Rückverteilungsvorgangs von Daten usw. ist es natürlich klar, dass man sich an Windows selbst usw. halten muß. Aber alles in einer Datei zu haben ist halt komfortabel, auch wenn es nur temporär ist (kann hier über mehrere Tage der Fall sein in den Dörfern der Eifel).

Ich habe meine Anwendung natürlich angepasst und Im- und Exportfunktionen gemacht damit der DB Abgleich auch funktioniert. Ist mehr als eine reine ini Datei.

Aber jetzt wird es OT, wir können die Diskussion hier beenden meiner Meinung nach.

Gruß
Frank
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Ein gewisses Unbehagen ... 
Autor: Manfred X
Datum: 18.06.17 02:11

Hallo!

Ich kann manches nicht so recht nachvollziehen.
Ini-Dateien und Registry-Einträge sind in Net-Anwendungen obsolet.
Ich vermute deshalb, Du beziehst Dich auf ältere Anwendungen, die noch
nicht völlig auf Net umgestellt sind.

Insbesondere wenn ein Mitarbeiter beim Kunden offline arbeiten muß,
sollten prinzipiell Datenbanken zum Einsatz kommen.
Wie im Beitrag oben angedeutet, etwa:
- eine DB für die lokal benötigten Datenbestände
- eine DB für datenbezogene Hilfsangaben (Parameter, Transformationen, Filter etc.)
- eine DB für die Settings-Variablen der eingesetzten Anwendungen

Einsammeln und Verteilen entfällt. Man benötigt nur Abfrage- und Update-Funktionen
für den Informationstransfer zwischen zentraler DB und lokalem Subset.
Zudem ergeben sich keine Sicherheitslücken, wie sie bei (temporärem) Einsatz
von XML-, INI- oder Registry-Zugriffen unvermeidlich sind.

(Wenn der Außendienst-Mitarbeiter eine mobile Antenne ausrichten kann,
steht meines Wissens flächendeckend schnelles Satelliten-DSL zur Verfügung.)
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Ein gewisses Unbehagen ... 
Autor: Schudi
Datum: 18.06.17 07:46

Jetzt muss ich doch mal etwas zu dieser Diskussion beitragen...bislang habe ich diesen "Abzweig" nur beobachtet weil er mir für mein Problem ziemlich OT vorkam...

Manfred X schrieb:
Zitat:


(Wenn der Außendienst-Mitarbeiter eine mobile Antenne ausrichten kann,
steht meines Wissens flächendeckend schnelles Satelliten-DSL
zur Verfügung.)


Nun gut, bei mir geht es nicht um Außendienstmitarbeiter sondern konkret z.B, um zwei Firmen, die eng zusammen arbeiten und daher normalerweise per Standleitung verbunden sind. Hier werden täglich tausende Datensätze z.B. Aufträge und Lieferavise aus diversen Gründen übermittelt. Aber die Standleitung fällt auch immer wieder aus. Mal für Sekunden und mal für Tage. Backup ist dann eine "normale" DSL-Leitung. Selbst hier würde man mich für den Vorschlag "Satelliten DSL" schlichtweg auslachen, obwohl hier jährlich Umsätze im 2-stelligen Millionenbereich gehandelt werden.

Ein anderes Beispiel wären Ladengeschäfte mit mehreren Kassen und WWS-Arbeitsplätzen. Hier müssen die Kassen genauso gut offline arbeiten können, als ob der Server erreichbar wäre. Alles andere würde nämlich bedeuten den Laden zu schließen bis Server oder Netzwerk wieder gehen. Und Sat-DSL ist hier absolut absurd. Viele solche Kunden haben nicht einmal einen "echten" Server sondern nur einen Windows Pc mit Freigabe. Hier spielen die Kosten bei vielen nämlich eine erheblich wichtigere Rolle als mögliche Sicherheitslücken durch INI-Dateien oder Registry-Einträge.

Wobei ich mich schon frage, in wie fern der Settings-Namensraum bei Nutzung ein Sicherheitsproblem darstellt...
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Ein gewisses Unbehagen ... 
Autor: Manfred X
Datum: 18.06.17 09:31

Hallo!

Die "Sicherheitslage" eines Systems hängt davon ab, welche
Informationen in ungesicherten Bereichen abgelegt sind -
bzw. von dort geladen werden.

Insbesondere auch bei digitalen Kassen-Systemen sollten alle
Einstellungen geschützt (oder zumindest verschlüsselt) sein.
Häufig ist es möglich, durch Manipulation von Nutzerprofilen
Geräte - teilweise - funktionsunfähig zu machen.
Falls noch nicht geschehen: eine Fachfirma für IT-Sicherheit
einschalten. Nur Spezialisten können zuverlässig eventuell
bestehende Lücken in einem System erkennen !!
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Ein gewisses Unbehagen ... 
Autor: Franki
Datum: 19.06.17 03:19

Hallo Manfred X
Zitat:

Ich kann manches nicht so recht nachvollziehen.

Mag sein, ich bei dir aber auch nicht.

Was du schreibst ist ja richtig, aber du verkennst die Situation in der Praxis meiner Meinung nach. Denn...

Zitat:


(Wenn der Außendienst-Mitarbeiter eine mobile Antenne
ausrichten kann, steht meines Wissens flächendeckend schnelles Satelliten-DSL
zur Verfügung.)


Ok mag sein, damit kenne ich mich nicht aus. Ich kann meine SAT Antenne auf meinem Wohnmobil manuell ausrichten, das ist kein Problem, aber damit kann ich dann TV/Radio empfangen aber noch lange habe ich damit keinn DSL bzw. Internet-Zugang.

Von meinen Kunden hat das auch niemand, und die Außendienstler schon gar nicht. Wie gesagt, ich kenne mich damit nicht aus, vermute aber mal, dass das "erhebliche" Kosten verursacht, DSL Zugang über SAT zu haben. Und das kann ich in meinen Anwendungen wirklich nicht als Voraussetzung integrieren für die Außendienstler.

Theoretisch mag das zwar funktionieren, in der Praxis eher nicht. Ich weiß ja nicht in welchem Bereich du so tätig bist, mag sein, dass SAT Empfang bei dir/deinen Kunden usw. möglich ist, bei mir ist es das definitiv nicht.

OT: Du scheinst dich damit ja auszukennen. Kannst du mir einen Link schicken, wie ich in meinem Wohnmobil DSL bekommen könnte was EU weit funktioniert bzw. kostengünstig ist? (Roaming ist ja jetzt angeblich kein Thema mehr). (Gerne per PM da ja hier OT)

Gruß
Frank
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Ein gewisses Unbehagen ... 
Autor: Manfred X
Datum: 19.06.17 16:20

Hallo!

Die Nutzung von Satelliten-"DSL" ist eine Notlösung für Business-Zwecke,
wenn sonst keine brauchbare Internet-Verbindung verfügbar ist.
Bei Satelliten-Übertragung kann es leicht zu Bandbreiten-Problemen kommen.
Man benötigt eine Vereinbarung mit dem Provider, die eine stets nutzbare
Mindestbandbreite fest zusichert!

Für DSL im Wohnmobil ist SAT zu aufwendig und zu teuer. Nie probiert.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Ein gewisses Unbehagen ... 
Autor: Franki
Datum: 20.06.17 00:23

Danke für die Info

Gruß
Frank
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Ergänzender Hinweis 
Autor: Schudi
Datum: 29.06.17 13:30

Ich habe das jetzt auf die Settings umgestellt, aber ich bin etwas irritiert....

Im Programm habe ich 6 Setting in den Projekteigenschaften definiert. Da ich kein Bild posten kann hier als Tabelle:

NeedUpdate Boolean Benutzer True
useMe Boolean Benutzer False
Wert1 String Benutzer
Wert2 String Benutzer
Wert3 String Benutzer
Wert4 String Benutzer

Unter User\Appdata\Local\Firmenname\Programname wird jetzt auch eine Datei user.config erzeugt. Diese enthält aber nur die letzten 5 Einträge. Die Einstellung "NeedUpdate" ist dort nicht aufgeführt.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <userSettings>
        <ProgrammName.My.MySettings>
            <setting name="useMe" serializeAs="String">
                <value>False</value>
            </setting>
            <setting name="Wert1" serializeAs="String">
                <value>AAAAA</value>
            </setting>
            <setting name="Wert2" serializeAs="String">
                <value>BBBBB</value>
            </setting>
            <setting name="Wert3" serializeAs="String">
                <value>CCCCC</value>
            </setting>
            <setting name="Wert4" serializeAs="String">
                <value>DDDDD</value>
            </setting>
        </ProgrammName.My.MySettings>
    </userSettings>
</configuration>
Im Programm sieht das wie folgt aus:

    Public Sub EinstellungenSpeichern()
    ' wird im Form_FormClosing aufgerufen
 
        If cboxUseMe.Checked Then
            My.Settings.useMe = True
        Else
            My.Settings.useMe = False
        End If
        My.Settings.Save()
 
    End Sub
 
    Public Sub EinstellungenLaden()
    ' wird im Form_Load aufgerufen
 
        If My.Settings.NeedUpdate = True Then
            My.Settings.Upgrade()
            My.Settings.NeedUpdate = False
            My.Settings.Save()
        End If
 
    End Sub
Außerdem wurde im Programmverzeichnis jetzt eine Programmname.exe.config zusätzlich angelegt. In dieser gibt es eine Kopie der user.config. Dort ist der Schalter "NeedUpdate" genau wie die anderen Werte mit aufgeführt.

Was mache ich falsch? Bzw. ist der "NeedUpdate" nicht mit in der user.config? Ich verstehe das nicht.

Ich nutze VS2015 Community Edition mit SP3.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Ergänzender Hinweis 
Autor: Manfred X
Datum: 29.06.17 17:08

Hallo!

Gewöhnlich steht die User.Config unter
User\AppDate\Roaming\(Kategorie)\Programmname\Version

Ob eine lokale Kopie angelegt wird, hängt von der Einstellung
im IDE-Fenster "Eigenschaften" der Settings-Datei in der Kategorie
"In Ausgabeverzeichnis kopieren" ab.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Ergänzender Hinweis 
Autor: Schudi
Datum: 29.06.17 18:27

Ja, dachte ich auch, dass die Datei in Roaming angelegt wird. Wird sie sie aber nicht, sondern in Local...

Ich wüsste auch nicht, wie ich das beeinflussen sollte. Gibt es da eine Einstellung für?

Aber das ist nicht die Hauptfrage. Mein Problem ist, dass die erste Eigenschaft "NeedUpdate" komplett "verschluckt" wird, also in der user.config gar nicht auftaucht.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Ergänzender Hinweis - gelöst 
Autor: Schudi
Datum: 30.06.17 08:51

So, selber gefunden.

Wenn man die Einstellungen in den Projekt-Eigenschaften anlegt, dann sollte man auch auf das Eigenschaften-Fenster achten.

Dort gibt es zu jedem Setting / Einstellung die Eigenschaft "Roaming".

Per Default steht diese - zumindest bei mir - auf "False". Damit wird die "User.config" im AppData-Unterordner "Local" erzeugt.

Ändert man den Wert "Roaming" auf "True, wird die user.config im Unterordner "Roaming".

Und wie durch ein "Wunder" ist dann auch meine "verschwundene" Einstellung mit in der "user.config".

---

Kurz gesagt: Ob die "user.config" mit den Einstellungen/Settings unter Local oder Roaming erzeugt wird, ist von der Einstellung im Eigenschaftenfenster jeder einzelnen Einstellung abhängig. Das ist leider etwas "versteckt".

Vielleicht hilft das ja dem einen oder anderen, der vor einem ähnlichen Problem steht.

Nochmals danke für jegliche in diesem und allen anderen Threads geleistete Hilfestellung.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.

Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
 
   

Copyright ©2000-2024 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel