I have upgraded a 60 KLOC Windows VB.NET application to VS 2012 and Windows 8.
Everything looked fine, except when I deployed it yesterday to ClickOnce.
The ClickOnce application is incredibly slow to load every form the first time that form is launched, IF the form uses binding. If a form is not using binding (but selecting data from a DB query) they load normally.
The most funny part is that while debugging in VS2012 they load in less then 1 second. When launched from the ClickOnce version they spend more than 60 seconds to load.
If I close one of these forms in the ClickOnce application and re-open it, they load normally in less then 1 second.
It seems that Binding in VS2012 is very bad the first time a form is loaded, but I prefer to think I'm doing something wrong.
Any ideas about this issue?
EDIT 2013/01/18:
After one day cutting unnecessary code, I have arrived to a solution that reproduces the slowness and that has no unnecessary code, so that it will be easier (I hope) to find what is not working proprly in it.
ClickOnce application is here:
http://www.octet.it/Reproduce/
Source files are here:
http://www.octet.it/Reproduce/Reproduce.zip
I can state that slowness is NOT depending on:
SQL Server (I have cut all the code that was accessing SQL server DB).
Binding (there is no binding at all, now).
Development environment: if you run the application from VS2012 it works as expected.
Instruction for reproducing slowness:
Install the ClickOnce application on a Windows 8 machine (mine is
x64, I had not a x86 to test).
Start Task Manager.
Start the "Reproduce" application.
When the MDI form has loaded, hit [Return] key (this will fire a MDIChild form).
Have a look at task Manager, showing how the "Reproduce" app will saturate one of the CPUs of your
machine and occupy about 650 MB of your RAM.
After about 45-60 seconds a MDIChild form will appear.
Close the MDIChild form.
Hit [Return] again and see the MDIChild appearing almost istantly and Task Manager showing no CPU saturation or RAM increases
As I told, before Win 8 the MDIChild (with binding and SQL acces to various tables) appeared in about 2-3 seconds.
Source files are not so interesting to see: they will just show a MDIparent form calling a MDIChild form, but I have included them in the .ZIP file if you want to do some experiments.
MANY thanks in advance for your time.
Let me know what I can do to solve this problem. Any suggestions is welcome.
How are you compiling the application? Are you targeting mixed platforms? Try targeting x86. I had a similar issue that was resolved by targeting x86 when I compiled, which should work fine on your x64 box unless you have some crazy x64 dependencies in your application. Note that this will change the clickonce manifest, which is a headache, but I'm curious if this fixes your issue.
Related
I have a desktop Windows Forms application I built.
As we try out improvements to the program, I make the changes on a test version of the application, which connects to a test copy of the Microsoft SQL database on the back end.
Basically, to start out, I just copied the program to a different directory, re-named the assembly, created a different PublicTokenKey and used that.
The problem is when I try to run a the test copy and the live copy at the same time. It pretty clearly thinks they are the same program (when I click on the second one, the "busy" circle simple turns for a second, then the already-opened icon in the taksbar gets highlighted), even though they show up in the Task Manager as differently named applications.
What do I need to tweak in Visual Studio so Windows 10 will recognize them as different, separate programs?
I have an Microsoft Access 2010 database application with split front end and backend which has started to behave oddly, and I've exhausted all the options I know for investigating and resolving the problem.
32-bit Access 2010 running on Windows 8.1... I have both Access 2010 and Access 2013 installed, but the problem also manifests itself on a Windows 8.1 system with a completely fresh install of Access 2010 and no Office 2013 present. The issue also exists if the application is run using Access 2010 Runtime. The front-end is running on my hard disk, not in a Dropbox or similar environment. The back-end is in Dropbox.
There are a couple of third-party elements in the application -- references are as shown -- example 1 on the system with both Access 2010 and 2013 present, example 2 on the system with just Access 2010 present.
There hasn't been a software update to the Treeview control since December 2013. I've checked that the versions of the third-party controls I'm using are compatible with Windows 8.1.
Symptoms:
The application (an unreleased development version) initially works perfectly, but if closed and reopened, one specific operation (right-click on a third party treeview ActiveX control on the main form) misbehaves -- the right-click event is triggered multiple times instead of just once (the number of times is unpredictable). There are two treeviews on the main form with identical settings (populated dynamically with different data sets). One treeview behaves, one doesn't. Even if I remove all code from the right-click event, it fires twice.
This main form configuration and code hasn't been changed in over one year, not has the treeview config or code. I don't use Compact on Close. The application isn't logging any errors.
What I've tried:
If I restore a previous version of the application, it works... and when reopened, doesn't work. (I've tried this with several previous versions of the database.)
I've tried importing a copy of the main form from an old working version of the database -- same problem.
I've tried deleting the malfunctioning treeview and creating a new one (copying the one that is working) -- same problem.
I've tried creating a new blank database and importing all the objects from the old one. Once I've restored the references manually, the same problem.
I've reviewed all the possibilities mentioned in Can't eliminate Access corruption -- one commonality I have with this question is that I've (last three months) started using the VBA Implements keyword, but I hadn't made any changes to this code immediately before the problem showed up, and neither the main form nor the treeview control utilise it.
I've emailed the support team for the treeview control, but they haven't anything to suggest that I haven't already tried.
I've repaired the installation of both Access 2010 and Office 365 in case the references were somehow messed up.
I've un-installed Office 365 and Access 2010, rebooted the machine and reinstalled Access 2010. The references are all Office 14 references and the problem still exists (in a compiled accde). As soon as I reinstall Office 365, the references become mixed 14 and 15. (This is also true for the working version which is two years old).
What I haven't tried yet:
Rolling back a two months' worth of Windows updates to see if it's a Windows issue (this system has only been in use since early September, so this wouldn't be hugely onerous to try).
Rolling back to a version of the app from December 2012 (the last production release) which doesn't seem to have suffered the corruption and manually reapply almost two years worth of development changes. This would be a mega undertaking....
Are there any other options for investigation or resolution that I can try?
Edited to add: What finally worked
I created a new empty database, imported everything from the old database except the main form, which I recreated from scratch to look identical and have the same code as the old one... And the problem has gone away. It not very satisfactory as a resolution, but it seems to confirm that there was a corruption somewhere.
One of the best ways to remove corruption in an Access database is to save the forms and reports to text using the undocumented SaveAsText function, delete the form and report objects, close the database, use the undocumented /decompile switch to decompile the database, compact/repair the database, then re-import all the objects using the undocumented LoadFromText function.
Usually the Access databases corruptions affect the VBA modules, less likely the table data. So hopefully you should be able to copy the data to a blank database, get the VBA code from a older backup (since the last source code update) and merging the two together. It should work!
It won't stay fixed unless you disable updates. And you can't disable updates because you will be compromising security.
I have an app in VBA consisting of many reports, queries, forms and tables. This .mdb file is linked to another .mdb file (the actual database for the app). This app was originally developed in Windows XP. But I have to move this app to run from a machine which has Windows 7. Now when I run a particular report in win 7 machine it throws an error.
The expression On Deactivate you entered as the event property setting produced the following error : A problem occurred while application was communicating with the OLE server or Active X component
When I comment out the Deactivate event from that particular report, the error is no more. But the interesting point is, when I use the same .mdb file to run from a XP machine, it works just fine.
I am very much confused. Any help will be highly appreciated.
Create a new report and, one by one, copy the controls from the previous report till the moment you get the error. The moment you got the error, discard that very control and recreate that very control again in the new report. After that copy the other remaining controls.
The idea is to pinpoint the control or controls which are causing the pain and then to discard those controls and recreate them again.
I have a Windows forms application which I have a bit of a sporadic issue with. The application would randomly start/spawn another instance of itself without any warning or reason. I only have one use of Process.Start in the whole application (15 forms/files and about 5000 lines of code) and that calls a net use command to map a network drive.
I've not been able to reproduce this in my testing and therefore I made the project a Windows Assembly Framework single instance application (pros/cons of this I know). This has obviously stopped any other instances of the application from running, but now at random intervals their program will minimise and snap to another application they have running. I don't know for certain whether this is related but they certainly sound a bit close for comfort!
Any ideas/pointers/thoughts appreciated.
Thanks,
Jamie
This could happen if the application, at some point, calls Application.Restart.
Everytime I execute my program, the main form closes by itself after about 15 seconds. The code is not the problem because it does the same thing when I put the whole code in comments. It's also not a key problem because it closes by itself even when I don't touch a single key when it's running. How can I fix it?
Do you use Avast antivirus? I was getting exactly the same problems with VS2010 (although I my project is a c++ application rather than VS). I notice the date of your post is around the 10 March which is when it started happening to mine.
I've just worked out that Avast was auto-sandboxing my exe file and terminating it after 15 seconds, that might be what was happening to yours too.
I just added the .exe to the list of exceptions in Avast and it completely fixed the problem.