.NET Framework - VISTA x64 + VS2008 SP1 Pro

Asked By Nik

23-Oct-08 05:04 PM

Guten Abend,

ich hätte einige kleinere Fragen zum Thema VS2008 SP1 Professional auf VISTA
x64 SP1.

Rechner: VISTA x64 SP1, VMWARE 6.0, 4 GB RAM, 3,2 Ghz Dual-Core.

Bevor ich VS2008 auf meinem richtigen Rechner (Host) installiere, habe ich
zunächst die Kombination (VISTA x64) innerhalb der VMWARE durchgespielt.
Dabei sind einige Probleme aufgetreten die ich vorher klären möchte.

1.
Dort gibt es z.B. ständig beim Debuggen eine AccessViolationException
(Plattform wurde schon auf x86 beschränkt) => könnte dies auch VMWARE
spezifisch sein?
=> wenn ich statt VISTA x64 in einer anderen VM XP x86 verwende (gleiches
Projekt) dann wird kein Fehler ausgelöst.

2.
Muss die  VS2008 IDE "als Administrator" gestartet werden, damit ich richtig
debuggen kann? => Hatte beides versucht aber  das Problem blieb bestehen.
Also nur mal die Frage, was nun richtig ist.
3.
Da ich neu in .Net agiere mal die grundsätzliche Frage: C# und VB.net sind
ja fast gleichwertig. Sind die Möglichkeiten der
Datenbankprogrammierung/Bindung unter VB und C# gleich bzw. gibt es darüber
irgendwelche Aussagen? (Ich komme aus der Foxpro Ecke)

PS: Ich möchte aber hiermit keinen "Streit" auslösen, welche Sprache die


Vielen Dank.

23-Oct-08 05:50 PM

Hallo Niko


ich denke schon, denn VS2008+SP1 läuft
eigentlich recht stabil.
Evtl. hilft eine neuere VMWare-Version (6.5?).
Bei VMWare gibt es angeblich auch ein
'Virtual Integrated Debugger' Add-In für Visual Studio,
welches Konflikte zu verursachen scheint.



ab VS2008 normalerweise nein:
http://msdn.microsoft.com/de-de/library/ms165100.aspx




--
Thomas Scheidegger - 'NETMaster'
http://dnetmaster.net/

24-Oct-08 01:54 AM

Hallo Niko,


Zunächst müsste die Fehlermeldung
und (ggf.) deren InnerException hier deutlicher
beschrieben werden. An welcher Code-Stelle
bleibt es denn stehen?

Kann es sein, dass Du das Projekt aus
einem VS2005 / XP Projekt geupdateted
hast? Es hört sich grundsätzlich mehr nach
Verzeichnissen/RegistryKeys an, die in Vista nicht mehr
dem User so eonfach zugänglich sind (etwa %ProgramFiles%,
einige neue Sicherheits-Schichten).

[Windows Vista für Entwickler: Kochbuch zur Anwendungskompatibilität]
http://msdn.microsoft.com/de-de/library/aa480152.aspx





Administrator nur notwendig bei Projekten,
die auch administrative Rechte benötigen, sonst nicht.
Bei Web-Projekten häufiger verbreitet.




Im Datenbankbereich sind beide Sprachen
funktional sehr ähnlich.
Aber im Sprachbereich würde ich ich doch
C# empfehlen.


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET

24-Oct-08 06:43 AM

Hallo Niko,


C# und VB.NET sind grundsätzlich gleichwertig und gleich leistungsfähig
(bezüglich der Performance gibt es wegen der gemeinsamen CLR-Basis
sowieso keinen Unterschied). Es gibt minimale Unterschiede - aber
eigentlich sind das nur Komfort-Features, die technisch nicht unbedingt
notwendig sind. In Bezug auf typische Datenbankprogrammierung brauchst
Du da aber keine Bedenken zu haben.


Ist ja auch keine die "Bessere". Chaotisch programmieren und Mist bauen
kann man in beiden gleich gut ...


Viele Grüße

Harald M. Genauck

24-Oct-08 06:45 AM

Hallo Frank,



Bezüglich letzterem wüsste ich nicht, wieso das der Fall sein sollte
...?


Viele Grüße

Harald M. Genauck

24-Oct-08 02:46 PM

Vielen Dank für die Antworten.

Also da ich ja erstmal anfange und das Konzept ja doch wesentlich weiter
bezüglich OO geht als unter Foxpro habe ich auch kein "altes" VS 2005
Projekt genommen, sondern ein neues erstellt und halt mal testweise mit
Toolstrip und Menü+ experimentiert. Wie gesagt in der VMWARE unter XP 32bit
funktioniert es ja.
Also würde ich behaupten, dass VISTA X64 in der VMWARE eventuell doch

Nun gut, da ich ja .Net lernen will mich nicht mit VMWARE Problemen plagen
will) werde ich wohl meinen realen Rechner mit VS2008 voll packen und hoffen
das so ein Problem da nicht auftaucht.

Der Projektordner liegt jedenfalls auf dem Desktop => vielleicht liegt es ja
daran.

Ich jedenfalls habe mich erstmal mit dem .Net Framework auseinander gesetzt
und da stellt sich mir noch eine kleine/große Frage.

Der JIT-Compiler:

Kompiliert der Compiler bei jedem Start der Anwendung die Applikation oder
legt er auf der Festplatte den Maschinencode ab, so dass er beim nächsten
Mal "weiß" was er bereits kompiliert hat? - Ich weiß ist schon eine komische
Frage,
aber will halt das Framework komplett verstehen, sonst kann es mit dem
Programmieren nicht wirklich gut werden.

Ach so Datenbankzugriff ist ja in .Net über Ado.Net und jetzt neu über LINQ
- vielleicht wirds ja irgend wann so leicht wie in FoxPro. :-)

Und nochmals Vielen Dank.

24-Oct-08 03:02 PM

Access-Exception:

Oh man wie b...  Der Order lag nicht auf meinem Desktop (nur eine
Verküpfung) sonder unter Laufwer C im Root => Schreibrechte.

Entsprechende Rechte gesetzt und keine Exceptions mehr.

Wie b.....

24-Oct-08 03:06 PM

ja...
(aber eher Methode für Methode vor deren ersten Aufruf)



nein, der native-Code ist nur im RAM.
Beim nächsten Programmstart wird wieder alles neu geJITet.


aber eine Möglichkeit wäre das NGEN Tool (->MSDN),
womit man für eine Assembly einmalig den
native-Code vorbereiten kann (in Datei).
(dies muss aber stets auf dem Zielrechner geschehen)
Hat aber nicht zwingend Vorteile (zB Performance).



naja,
FoxPro war IMHO primär halt weitgehend
auf DB-Zugriff 'ausgerichtet',
bei C# / .NET gehen die Anwendungsfälle
enorm viel weiter,
=> generische / universelle Plattform.





--
Thomas Scheidegger - 'NETMaster'
http://dnetmaster.net/

24-Oct-08 03:31 PM

Abschließend noch eine kurze Frage zum Thema Schutz des Quellcodes.

Meine Erkenntnis:
Grundsätzlich kann  der IL Code (ILDasm) eingesehen werden, durch den
Obfuscator können die Methodennamen etwas "verschleiert" werden, aber
grundsätzlich auch durch nachvollziehen/debuggen wieder in die richtige
Abhängigkeit gebracht werden. Außerdem hat dies auch Performanceeinbußen zur
Folge.


Durch z.B. NGEN oder andere käuflich zu erwerbene Software, welche nichts
anderes macht als den IL-Code in Maschinencode sofort umzuwandeln bzw. zu
ummanteln, kann dies verhindert werden. Nur dann wären wir ja wieder bei der
Auslieferung  von nativen Code, also Architektur-bezogen.

Bei VFP konnte man die exe mit extra Tools z.B. Refox stark verschlüsseln.

Nun zu der eigentlichen Frage:

Um die "plattformunabhängikeit" von .Net nicht zu verlieren bin ich gezwungen
Nur durch "Vertrauen" bzw. über die Dienstleistung?

24-Oct-08 03:57 PM

Hallo Niko,


Windows-Systeme.


Am besten ja.

Aber auch:
http://www.microsoft.com/slps/
(Artikel dazu in der VISUAL STUDIO one 05/08)


Viele Grüße

Harald M. Genauck

24-Oct-08 04:01 PM

ja, 'by design'...


stimmt...



naja, kommt auf die Art/Tiefe der 'Verschleierung' an...



NGEN ist in keiner Art & Weise ein Schutz.
Die damit erstellten native-Images enthalten _auch_
weiterhin den MSIL-Code eingebettet!
(und wie gesagt, NGEN wird erst auf Zielrechner eingesetzt)




ich persönlich halte nahezu nichts von Obfuscators
oder weitergehenden Verfahren.
Man sollte mit Konzepten & Service überzeugen
und sich von der Konkurrenz abheben.
Und kopiert wird oft sowieso,
auch ohne Zugriff auf SourceCode/MSIL
(zB GUI/Formulare)

Primär ist es eine fragwürdige geschäftemacherei,
selbst Microsoft mischt da selber auch mit:
http://www.microsoft.com/slps/
wobei hier immerhin die Lizenzierung mit 'gelöst' werden kann.
Man beachte, andere Tools stammen da meist
von _sehr_ kleinen Firmen,
wo man in riskante Abhängigkeiten geraten kann.

Wenn bestimmte Methoden/Algorithmen wirklich
_echt_ schützenswert sind,
dann wäre evtl. Codierung gleich in C/C++ überlegenswert.




--
Thomas Scheidegger - 'NETMaster'
http://dnetmaster.net/

24-Oct-08 04:45 PM

oha, gemäss


scheint SLPS wohl 'abgeschossen'.




--
Thomas Scheidegger - 'NETMaster'
http://dnetmaster.net/

25-Oct-08 12:42 AM

Hallo Niko,


zum Beispiel:

[www.EZIRIZ.com ...To Be One Step Ahead]
http://www.eziriz.com/

Beachte, dass es auch für unmanaged exe
Tools gibt, die das wieder entschlüsseln.


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET