When deploying my Silverlight app, everything seems to be working until the screen goes black (just before the app starts loading) and Visual Studio gets to the "Launching UI Task" part of the build. Visual Studio is then unresponsive for about 60-90 seconds, during which time the screen remains black.
Finally, Visual Studio will become responsive again, the initial splash screen will load and the app will launch. However, it will hang again when I hit the "stop" button, this time for longer. It does this on a deploy to a device and to the emulator and it only does this for this one app (other projects deploy just fine).
It also does not hang when I do a non-deploy build. Cleaning and rebuilding the solution has no effect.
I'm using Visual Studio 2010 SP1 (Version 10.0.40219.1 SP1Rel). If you think I'm missing any helpful information, please let me know.
I had this problem as well. I remembered from long ago I found a post that stated if there was an invalid breakpoint, startup time could take forever. I deleted the .SUO file (which stores the breakpoints) and everything was back in order.
Related
I am expierencing a strange problem with Visual Studio 2019. We ware using SOAP-webreferences in our projects. When I start a project in debug mode, the debugger freezes when the SOAP reference is instantiated. Waiting ~5 minutes helps but this problem strongly impaires the development. When I start the same App without the Visual Studio debugger, everything works fine. The bottom line is that I cannot use the debugger right now.
I already tried to set a breakpoint but nothing happens when the debugger freezes - even in the console.
Visual Studio 2019 freezes when instantiating SOAP Webreference
Please try the following steps:
1) disable any third party vs installed extensions under Extensions-->Manage
Extensions to check whether there is an extension causing that.
2) reset all vs settings under Tools-->Import and Export Settings-->Reset all VS settings
3) clean nuget caches first
then run update-package -reinstall under Tools-->Nuget Package Manager-->Package Manager Console
4) close VS, delete .vs hidden folder under the solution folder, bin and obj folder
5) try to use another port under Project Porperties-->Web-->Porject Url https://localhost:<prot>/ like https://localhost:44307/
6) Or try run devenv /safemode on Developer Command Prompt for VS2019 to start a pure VS and then debug your project to test again.
7) If it does not work, you could create a new winform project in VS2019 and then migrate the old content into the new one to test whether the issue still persists. And if it succeeded, it is a better solution to avoid this issue.
If the error also happens on the new one, please repair vs or update vs.
Besides, if these do not work, please share a small sample with us so that it will help us troubleshoot your issue more quickly.
When I run the application in Visual Studio, some screens are not visible!
Screens when App is started in VS 2012
The currently deployed version on the web server, shows all screens.
Published Version
I cant publish now, since not all screens are shown.
im hoping its going to be an issue as simple as this, if you go to your Project Properties, and check that the "Granted for debug" options are ticked. basically if these aren't ticked, then it will compare all your screens against the "TestUser" rather than the Administrator you are logging in as on your live version.
when they are check you are effectively ignoring the permissions so you can see everything while programming it. Ticking these has no affect over your live project.
Hope this helps
I've been using Inspect.exe from the Windows SDK to examine the properties of a WinForms application but noticed that I didn't see any of the properties (for example, the AutomationId) whilst running the application from Visual Studio (F5 to run.) However, if I ran the .exe from the bin\debug folder I could see the properties fine.
The source I was using was example code downloaded from UI Automation Custom Provider Samples - Part 3.
I'm wondering why this happened since I'm sure another machine that I had tried this on worked fine and I wasted time poking around in debug mode wondering why my UI Automation properties weren't visible. Obviously there's a workaround but I'd like to understand why this was happening and have a record of the problem for other people to find!
I've struck upon the answer - because I had launched Visual Studio as Administrator but the Inspect.exe tool as standard user then the properties being reported back were a sub-set of what I should have seen. As soon as I launched Inspect.exe as Administrator it worked!
I'm running Visual Studio 2010 and using Team Foundation Server, and this thing is pissing me off no end.
Here's the scenario: since I work from home it often happens to me to work at strange hours or on the week-end, when our TFS is offline. This has never been a problem, since usually I just reload the solution and when VS detects that the TFS is not available it promprts you to work offline.
Now, I usually work on WPF projects, and working offline has never be a problem, even when editing XAML files it works with no issues. But now I have to edit a Form from a Windows Forms project, and VS refuses to collaborate. Whatever I do to the form, VS just does nothing other than playing that obnoxious "bing" sound that usually plays when an error of some kind occours. It doesn't even popup an error dialog box, just does nothing!
Any ideas??
Ok figured it out, I had to remove the "Read Only" attribute from ALL the files in the project (I had tried with the project file and form file, but that isn't enough evidently).
I have a problem with ClickOnce publishing of a WPF application.
If the application is built (debug or release), it is running correctly.
Application published by ClickOnce crashes.
I tried to change Target Platform. Sometimes this change helps to solve problems, but not every time (1 of 20 cases).
I have Visual Studio 2008 and the project has been upgraded from Visual Studio 2005.
Any ideas?
Thank you in advance!
On the machine where the application is installed, drill down in the user profile to the ClickOnce cache, and look for the cached application files. The folder will have the exe and all of the assemblies, etc., in it. Our winform app creates two folders, xxxx_tion is the one the application runs from.
Find the exe file and double-click on it to run it. This essentially runs the application without the ClickOnce-ness of it all. If it crashes, then it is not a ClickOnce problem per se, it is a problem with your application.
I would check and make sure you are deploying all of the files you need, you don't have references to multiple versions of the same dll, you don't have circular references, etc.
Good luck,
RobinDotNet
There is a long discussion on http://social.msdn.microsoft.com/forums/en-US/wpf/thread/3e6909ef-2ab1-4b77-8bc2-796c065a6219/
Solution that worked for me (send by pindurav on page above):
I rebuild whole solution
close visual studio
open visual studio, open project and directly publish without building.
= no app.xaml exception