Applicatie erg traag na installatie, zonder admin rechten

[Lexus!]

Of het echt met programmeren te maken heeft weet ik nog niet, wellicht staat mijn topic niet op de juiste plek.

De applicatie waar ik het over heb, is door mij geschreven in VB.NET Express 2015 (Windows 10). De uitlevering doe ik via Advanced Installer. Dit ging een poos goed, tot een onbepaald moment. Nu draait de geïnstalleerde applicatie wel, maar enorm traag (bv laden van formulier van 0,6 naar 10,5 sec). Start ik de applicatie met admin rechten dan is er niets aan de hand. Dit is zowel op mijn eigen pc als bij anderen.

De mappen bin/release en de installatiemap heb ik met elkaar vergeleken. Identiek. Zowel in de ontwikkelomgeving als de exe in bin/release starten en draaien snel en goed. Om Advanced Installer ook uit te sluiten heb ik de bestanden 1 op 1 gekopieerd naar de programfiles map, ook dan is het direct traag.

Code signing heb ik om te testen uitgezet, geeft geen verschil.
Advanced Installer heb ik in principe ook uitgesloten door de bestanden te kopieren
Als ik de msi van een oude versie pak dan heb ik het probleem niet, helaas is er te veel veranderd om de verschillen te zien. Het is een vrij nieuwe applicatie.

Het lijkt erop dat het dus met rechten te maken heeft. Hoe kan ik dit verder uittesten, of waar zou dit specifiek aan kunnen liggen?

[Slurpgeit]

Ik zou eens beginnen met process monitor starten en kijken waar je programma eventueel op blijft hangen:

https://technet.microsoft...rnals/processmonitor.aspx

[MAX3400]

Lexus! schreef op woensdag 18 mei 2016 @ 10:13:

Als ik de msi van een oude versie pak dan heb ik het probleem niet, helaas is er te veel veranderd om de verschillen te zien. Het is een vrij nieuwe applicatie.

Het lijkt erop dat het dus met rechten te maken heeft. Hoe kan ik dit verder uittesten, of waar zou dit specifiek aan kunnen liggen?

Ongedocumenteerd changelog? & https://technet.microsoft.com/en-us/sysinternals

Ik vraag me trouwens af of het probleem zich voordoet op meerdere OS'en of alleen op Windows 10; daarnaast mis ik een beetje of je basale troubleshooting, zoals UAC, al hebt uitgevoerd.

[Lexus!]

Slurpgeit schreef op woensdag 18 mei 2016 @ 10:15:
Ik zou eens beginnen met process monitor starten en kijken waar je programma eventueel op blijft hangen:

https://technet.microsoft...rnals/processmonitor.aspx

Hij blijft hangen op de toegang tot een SQLite .db bestand: ACCESS DENIED:
Desired Access: Generic Read/Write
Disposition: OpenIf
Options: Synchronous IO Non-Alert, Non-Directory File
Attributes: N
ShareMode: Read, Write
AllocationSize: 0

Voor zover ik weet is er niets veranderd aan het aanroepen van dit bestand.

MAX3400 schreef op woensdag 18 mei 2016 @ 10:17:
[...]

Ongedocumenteerd changelog? & https://technet.microsoft.com/en-us/sysinternals

Ik vraag me trouwens af of het probleem zich voordoet op meerdere OS'en of alleen op Windows 10; daarnaast mis ik een beetje of je basale troubleshooting, zoals UAC, al hebt uitgevoerd.

Het ontwikkelen van software is niet onze core business. We houden wel degelijk een changelog bij, maar niet van elke letter die we in de broncode veranderen.

Het probleem doet zich ook voor op Windows 8 heb ik net getest.

UAC op minimaal geeft geen verschil.

Wat betreft troubleshooting, dit is juist mijn vraag, hoe kan ik verder zoeken. Signing uitgezet, onwikkelomgeving vs bestanden in programfiles getest, oude versie geinstalleerd en getest, deployment software uitgesloten, het is niet dat ik niets geprobeerd of niet vermeld heb toch?

[Haan]

Lexus! schreef op woensdag 18 mei 2016 @ 10:50:
[...]

Hij blijft hangen op de toegang tot een SQLite .db bestand: ACCESS DENIED:

Nu dat je weet waar het precies mis gaat, lijkt me de volgende stap om je data access code te onderzoeken waarom de access denied wordt, plus dat je de applicatie in je ontwikkelomgeving ook met beperkte rechten zou moeten laten draaien om het probleem daar gereproduceerd te krijgen.

[Montaner]

Wat zijn de rechten op het .db bestand? Als je daar bv. Everyone full control op geeft, nog steeds hetzelfde issue?

[Lexus!]

trix0r schreef op woensdag 18 mei 2016 @ 11:10:
Wat zijn de rechten op het .db bestand? Als je daar bv. Everyone full control op geeft, nog steeds hetzelfde issue?

Dit lost het snelheidsprobleem inderdaad op. Alleen lijkt me dit niet een juiste oplossing, wellicht is het dus beter om dit bestand niet binnen de applicatiedir mee te leveren maar in een lees/schrijf veilige locatie.

Wel vreemd dat ik hier niet eerder tegenaan gelopen ben eigenlijk.

[Montaner]

Lexus! schreef op woensdag 18 mei 2016 @ 11:17:
[...]


Dit lost het snelheidsprobleem inderdaad op. Alleen lijkt me dit niet een juiste oplossing, wellicht is het dus beter om dit bestand niet binnen de applicatiedir mee te leveren maar in een lees/schrijf veilige locatie.

Wel vreemd dat ik hier niet eerder tegenaan gelopen ben eigenlijk.

Nu weet je wel dat de gebruiker die de applicatie uitvoert geen toegang heeft tot het bestand . Een oplossing is het inderdaad niet. Mogelijk dat je vorige installer de rechten aanpaste.

[Janoz]

Lexus! schreef op woensdag 18 mei 2016 @ 10:50:
Het ontwikkelen van software is niet onze core business. We houden wel degelijk een changelog bij, maar niet van elke letter die we in de broncode veranderen.

Dat kun je toch gewoon uit versiebeheer halen? Laatste versie die nog werkte vergelijken met de huidige en je weet exact waar alle wijzigingen zijn geweest.


Maar inderdaad. Het is ene big nono dat een applicatie kan schrijven in de applicatie directory. Dat is nogal een security issue. Elk OS (dus ook Windows) heeft daarvoor een aparte folder.

[Woy]

Lexus! schreef op woensdag 18 mei 2016 @ 11:17:
[...]
Dit lost het snelheidsprobleem inderdaad op. Alleen lijkt me dit niet een juiste oplossing, wellicht is het dus beter om dit bestand niet binnen de applicatiedir mee te leveren maar in een lees/schrijf veilige locatie.

Het is inderdaad niet handig om files die aangepast dienen te worden in de applicationDir mee te leveren. Daar heb je verschillende mogelijkheden voor ( ApplicationData, CommonApplicationData zijn de meest voor de hand liggende: https://msdn.microsoft.co...cialfolder(v=vs.110).aspx )

[Haan]

Maar staat de database nu niet in de App_Data map dan? Want dat zou toch ook gewoon moeten werken.

[Lexus!]

Nee, dit bestand wordt in een submap binnen de applicatiedir meegeleverd. Foute keuze inderdaad, ontstaan door de onwetendheid hoe ik ook al in de ontwikkelomgeving deze bestanden direct naar de App_Data map kan builden. Vanuit de deployment kan ik keurig aangeven welke bestanden ik waar wil hebben, maar hoe ik dat tijdens debuggen in VS kan doen ben ik aan het uitzoeken, nog geen flauw idee namelijk.

Het bestand wordt nu keurig in de AppDir gezet, probleem opgelost. Dank u allen!

[ Voor 9% gewijzigd door Lexus! op 18-05-2016 13:07 ]