Witam,
ostatnio napisałem prosty program, ściągający pliki z różnych serwisów(wrzuta, youtube i te sprawy).
Program działa bardzo dobrze na systemach Windows xp(na tym systemie też go kompilowałem), jednak już na Viście program nie pobiera plików.
Teraz czas na moje pytanie ;-P
Jest jakiś sposób, aby program działał na systemie Windows Vista, bez ponownego kompilowania go(w Viście)?
Pozdrawiam :-)
Co to znaczy, że nie działa?
Nie uruchamia się? Rzuca wyjątki?
Uruchamia się normalnie, po dodaniu pliku wyświetla się jego nazwa(listview),tworzy plik, ale nie zaczyna ściągać.
Musi być jakiś powód czemu nie zaczyna ściągać. Jeśli chcesz dać dostęp aplikacji do sieci, to uruchom aplikację wf.msc i dodaj "Nowa reguła..." dla aplikacji. W każdym razie podaj powód dlaczego nie zaczyna ściągać. Jeśli leci wyjątek, to nie chowaj go tylko wyświetl na konsole lub zapisz do pliku. Wtedy nie trzeba zgadywać co konkretnie zawiodło.
Wyjątków nie wyrzuca, troche potestowałem i wszystko z funkcji działa, oprócz DownloadFileAsync
Pytanie tez, gdzie chcesz ten plik zapisac? Moze na Vista probujesz zapisac do folderu chronionego przed zapisem dla Twojego uzykownika?
co to za metoda DownloadFileAsync?
jesli to frameworkowa to z jakiej klasy
a jesli twoja to daj jej kod i kod obslukujacy koniec operacji asynchronicznej
Plik zapisuje w katalogu "sciezkaprogramu/Pobrane", lub w innym, wybranym w ustawieniach przez użytkownika.
DownloadFileAsync jest funkcją klasy WebClient(System.Net)
oski225 napisał(a)
Plik zapisuje w katalogu "sciezkaprogramu/Pobrane"
Nie wolno zapisywać do Program Files.
No cóż, kolejny amator pracy na roocie na XP... Tym z Microsoftu za brak wymuszenia konta usera powinno się jądra wypreparować.
... napisał(a)
No cóż, kolejny amator pracy na roocie na XP... Tym z Microsoftu za brak wymuszenia konta usera powinno się jądra wypreparować.
Od Win 7 de facto wreszcie wymuszaja. Nawet admin nie jest juz tak naprawde adminem ;)
Już próbowałem na innym dysku, niestety dalej bez efektu. Bardzo dziwna sprawa...
johny_bravo napisał(a)
Od Win 7 de facto wreszcie wymuszaja. Nawet admin nie jest juz tak naprawde adminem ;)
A w Viście nie wymuszali?
oski225 napisał(a)
Już próbowałem na innym dysku, niestety dalej bez efektu. Bardzo dziwna sprawa...
Najwyraźniej pierwszy z cudów Tuska ;P
A tak na serio - masz możliwość odpalić program pod Vistą w debugerze? Bo chyba bez tego to tylko zgadywać można.
Nie, w Viscie ostrzegali.
@autor: odpalasz aplikacje na koncie uzytkownika? Odpal w tym trybie i sprawdz czy pokaze sie okienko z pytaniem o podniesienie do praw admina.
Oprocz tego luknij na to http://www.microsoft.com/downloads/details.aspx?FamilyID=24DA89E9-B581-47B0-B45E-492DD6DA2971&displaylang=en
johny_bravo napisał(a)
Nie, w Viscie ostrzegali.
Hmm... Czy ja o czymś nie wiem?
somekind napisał(a)
johny_bravo napisał(a)
Nie, w Viscie ostrzegali.
Hmm... Czy ja o czymś nie wiem?
Mozliwe. W Viscie przy podniesieniu uprawien dostajesz uprawienia administratora po prostu. W Win 7 zostajesz tym samym uzytkownikiem, ale dostajesz wyzsze prawa dla tej aplikacji tylko, nie wszystkie prawa i jeszcze w danym kontekscie. Innymi slowy nie stajesz sie adminem, a dla tej jednej sytuacji nabywasz czesc jego praw. Troche zagmatwane, ale lepsze rozwiazanie. Aaa, no i w zwiazku z tym rozwiazaniem nie logujesz sie na konto administratora, a zwyklego uzytkownika w zasadzie zawsze.
Hmm... A z praktycznego punktu widzenia, to czy kiedykolwiek nie mogę zrobić tego, co mogłem zrobić do tej pory? (Z instalacją Win7 czekam na większy dysk ;))
Z programistycznego punktu widzenia Win7 pozwala na troche mniej i jest zgodny (nie wiem czy w 100%) z podejsciem LUA. Nie mozesz teraz na przyklad podmienic dllek systemowych - jest pelna blokada. W XP byl dllcache, w Viscie byla fasada udajaca, ze udalo sie je zapisac.
Generalnie roznic nie ma wiele z punktu widzenia uzytkownika, ale z programistycznego zostalo to ujednolicone i posprzatane. Tak przynajmniej twierdzil Microsoft :) Po wiecej szczegolow musialbym zerknac do materialow ze szkolenia na ten temat ;)
somekind napisał(a)
oski225 napisał(a)
Plik zapisuje w katalogu "sciezkaprogramu/Pobrane"
Nie wolno zapisywać do Program Files.
Ej, a jeśli chciałbym aby program przechowywał swoje dane, np. konfigurację we własnym katalogu, to co?
Piszę program, który ma być dosyć przenośny (znaczy wszystko, co jest mu potrzebne w tym dane oraz pliki tymczasowe przechowuje we własnym folderze oraz nie jest zależny od żadnych danych poza nim prócz frameworka). Czy znaczy to, że nie będzie możliwe uruchomienie go na Viście i win7?
To zapisujesz do katalogow wolnych, np. Dane uzytkownika, dla wszystkich uzytkownikow, temp, itp. Jest ich do woli.
Pomysl jest ok, chodzi o to, zeby zaden program nie mial normalnie dostepu do execow, ktore moglby, np. zarazic. Zreszta w linuksie jest to chyba od dawna.
Nie nazwał bym tego dobrym. Od poczatków mojego programowania wyznawałem zasadę jednego folderu (wszystko co jest w programie powinno znajdować się w tym samym folderze), a tu kicha.
Nie podoba mi się pomysł rozprzestrzeniania aplikacji na 20 folderów:
-C:/DocumentsAndSettings/xxx/Dane Aplikacji
-C:/DocumentsAndSettings/xxx/Ustawiania lokalne/Dane Aplikacji
-C:/DocumentsAndSettings/xxx/Temp
-C:/Windows/Temp
-C:/Program Files/MyApp
-Rejestr
-...
Nie dość że problematyczne jest utrzymanie porządku w tym śmietniku, program może działać na kompie developera, a na innych nie, bo ten jako jedyny ma jakiś tam stary plik.
Do tego testowanie kilku wersji jest niemożliwe, bo każda zacznie robić bałagan w Tych wspólnych folderach.
Inną sprawą jest to, co przeżywam przy każdej reinstalacji Windowsa - przeszukiwanie tego całego śmietnika i zastanawianie się, czy zarchiwizowałem wszystko co trzeba.
A przy okazji, ciekawe jak bez możliwości pisania w Program Files miały by działać aktualizatory.
Czy istnieje sposób, aby program w Windows Vista i Win7 dostał zezwolenie (stałe bez ciągłych pytan o udzielenie praw admina) na grzebanie w plikach z własnego katalogu i podfolderów?
Przesadzasz.
-C:/DocumentsAndSettings/xxx/Dane Aplikacji
-C:/DocumentsAndSettings/xxx/Ustawiania lokalne/Dane Aplikacji
-C:/DocumentsAndSettings/xxx/Temp
-C:/Windows/Temp
-C:/Program Files/MyApp
-Rejestr
Pozostaje punkt 1. Co do przegladania smietnika -> przegladasz katalog swojego profilu i po sprawie. Inna kwestia, ze wina nie reinstalowalem dobre 2 lata.
Kolejna kwestia - zapisujesz w jednym katalogu, nie ma smietnika. Program pisze sie tak, zeby byl niezalezny od braku plikow. Jesli nie znajdzie, niech tworzy plik z pustymi ustawieniami, pusta baze, itp. Po sprawie.
Co do aktualizatorow -> kazdy program moze dostac prawa dostepu, jesli uzytkownik wyrazi na to zgode, nie ma problemu.
Ostatnie pytanie: w Win7 istnieje mozliwosc tworzenia tzw. shims, czyli stworzenia obejscia dla kazdego z brakow funkcjonalnosci, czy symulowania pewnego zachowania. UAC chyba tez dalo sie wylaczyc, o ile pamietam. Przy czym nie jest to najlepsze postepowanie, bo tworzysz luke w bezpieczenstwie.
Dwa katalogi, jeden na program, drugi na dane, bo program jest wspólny, a każdy użytkownik może mieć swoje dane. Zaś rejestr jest na ustawienia systemowe i w ogóle najlepiej go nie ruszać.
johny_bravo napisał(a)
UAC chyba tez dalo sie wylaczyc, o ile pamietam.
Ja mam wyłączone, właśnie przez debilnych programistów, którzy tworzyli programy trzymające dane razem z programem, a które nie bardzo mam jak zastąpić, np. KonnektPlus.
hubert_nnn napisał(a)
A przy okazji, ciekawe jak bez możliwości pisania w Program Files miały by działać aktualizatory.
Na przykład tak: http://msdn.microsoft.com/en-us/library/aa372388%28VS.85%29.aspx
@somekind: shim ustawia sie dla danej aplikacji, wiec nie trzeba wylaczac dla calego systemu :) Zreszta to byla najwieksza pomylka z Vista - wszyscy mysleli, ze to Vista taka upierdliwa, a to programy po prostu zle dzialaly, a uzytkownicy od zawsze siedza na adminie ;) Zreszta developerzy tez rzadko zauwazaja, ze cos jest nie tak, bo tez na adminie siedza.
somekind napisał(a)
Ja mam wyłączone, właśnie przez debilnych programistów, którzy tworzyli programy trzymające dane razem z programem, a które nie bardzo mam jak zastąpić, np. KonnektPlus.
W trzymaniu danych razem z programem nie ma nic złego, daje to przenośność (można np. program zainstalować na pendrivie i na każdym kompie jest to samo), uniwersalność (.Net to także mono, a na linuksie chyba nie znajdziecie Documents Adn Settings) i wygoda (chcesz przenieść lub usunąć program, to robisz to z katalogiem).
Przy okazji nie ma też problemów z deinstalacją, bo chyba każdy zna programy, które po usunięciu pozostawiają tyle po sobie (rejestr, doc and sett, folder windows ...)
O UAC Patching będę musiał sobie w sobotę poczytać trochę, dzięki za link, może jednak uda się coś zrobić z Vistą
A jeszcze takie pytanie, pisać nie można w C:/Program Files/MyApp
A co jakbym program instalował np w C:/HubertApps/Myapp?
Jest cos zlego, bo dajac dostep do Program Files pozwalasz kazdemu pisac gdzie chce, rowniez po innych aplikacjach. To jest problem. Jak chcesz zainstalowac aplikacje gdzie indziej, to nie ma problemu, ryzyko Twoje i uzytkownika aplikacji. Trzeba tez pamietac, ze dostep do dysku systemowego tez jest zablokowany. Co do linuksa i Documents And Settings, to przeciez w .net jest klasa, ktora przechowuje sciezke do tego katalogu, jest tez zmienna systemowa. Nie nalezy ukladac tej sciezki recznie.
@hubert_nnn, odnośnie Mono:
http://www.go-mono.com/docs/index.aspx?link=M%3ASystem.Environment.GetFolderPath
Jeśli chodzi o przenośność, to faktycznie przechowywanie w katalogu aplikacji jest najlepsze, lecz tylko w przypadku gdy aplikacja ma być portable. W przeciwnym razie, np. przeinstalowywanie systemu, wolę kopiować katalog użytkownika niż cały katalog "Program Files". I tak sporo programów z katalogu "Program Files" po instalacji będzie działać nieprawidłowo, a spamiętać, który program gdzie zapisuje ustawienia, nie sposób. Więc przywracam pliki z katalogu użytkownika i ponownie instaluje programy, które są mi potrzebne. Jeśli program ma już ustawienia, które przechowałem podczas reinstalacji, to po instalacji tego programu on po prostu użyje starych ustawień.
Odnośnie instalacji, to praktycznie każdy program instalacyjny podnosi uprawnienia przed instalacją. Dlatego może swobodnie zapisywać do zabezpieczonych katalogów. Program może robić podobnie, ale jest to uciążliwe. Już lepiej nie pozwalać na instalację programu w zabezpieczonych katalogach lub odradzać to użytkownikowi (co też wielu użytkownikom nie musi się podobać).
Największy jednak problem jest nie w samych zabezpieczeniach i UAC, lecz w przyzwyczajeniach użytkowników Windowsów wyrobionych przed wydaniem Visty. Nadal większość ludzi instaluje 50 antywirusów i wyłącza UAC...
Tak a propos pisania do \Program Files to Vista wirtualizuje ścieżki - program myśli, że zapisuje tam gdzie trzeba, odczytuje tak jak trzeba, a pliki tak naprawdę lądują w VirtualStore. Ale przyznam, że ja nie wiem jakie są warunki by to działało - bo na obecnym systemie mi dla niektórych aplikacji działa, a na poprzednim nie działało dla żadnej oprócz Apache (i stąd miałem chore problemy z konfiguracją, ale zrozumiałem to znacznie później).
Nawiasem mówiąc to do \Documents and Settings też nie wolno zapisywać - bo np. w Viście takiego katalogu nie ma jak wiadomo - po to są zmienne środowiskowe by z nich korzystać :-)
Jako "ominięcie" problemu braku możliwości zapisu do \Program Files istnieją programy, które się po prostu do "Danych aplikacji" instalują - Google Chrome na przykład. Albo Microsoft Live Mesh. To daje możliwość zainstalowania, nawet jeśli użytkownik nie ma praw administratora. Ale absolutnie takiego zachowania nie polecam, jest miejsce na aplikacje i miejsce na dane.
Z tego co pamietam virtualizuje, jesli UAC jest wylaczone. W przeciwnym przypadku spyta o zgode uzytkownika.