Apologies if this has already been asked or not doable, but when I code in IOS or Eclipse I can make code changes even if the app is running on my device while testing some aspect. I then just rebuild and it restarts the app on the device with the modified code.
Is there a way I can do the same with Visual Studio 2012? It is very annoying if I forget to stop the device from testing the app and try type in code only to be prevented from making changes. Not a show stopper I know, but if there is a setting some where it sure would be helpful.
So in a nutshell, I want to run some code on my device (lumia 520), note an issue, make the change in MainPage.xzml.cs or elsewhere and then just restart the build and it will stop the app running on the device and restart it with the modified code.
I will keep looking myself but as it always the case, sometimes its harder to find the right question to ask than get to the answer. Hope the question makes sense and appreciate any suggestions.
Seems as its a default way Visual Studio works as I get the same issue with Visual Studio 2013. Could not find anything in OPTIONS so will leave it at that.
Related
I followed the instructions in this link: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx to install the remote debugger (2012) on my server where the application is running in hope to debug it remotely from my dev machine running visual studio 2012.
I cannot even get as far as viewing the list of processes to attach to on the remote machine. I keep getting "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named [name]. Invalid access to memory location".
I have managed to successfully connect a few times but then the attach fails immediately then I cannot connect again.
This is causing huge issues for me as I cannot remote debug anything. I must be missing something glaring. Please someone give me a solution.
I've found the only way to correct this is by restarting Visual Studio.
Worked for me. I found it at this blog post about invalid access and remote debugging.
It turns out the one thing I missed was to tell Visual Studio where to find the .pdb symbols relating to the remote process. To do this go to Tools -> Options -> Debugging then in the Symbol (.pdb) locations add the remote location to the pdb files.
To clarify, I was attaching fine but could not break into code. Now I can. Be aware though that there are other hurdles before you get to my stage where I was attaching to the process successfully but could not catch a breakpoint.
I recently had someone else report this and debugged the issue on their machine. The "Invalid access to memory location" errors are due to an issue in Windows, it can be addressed with this hotfix.
I have had this problem in VS 2012, 2013, 2015 and 2017. Based on other answers it is likely that the problem is related to running a 32 bit version of Visual Studio on a 64 bit PC. Sometimes, as others have recommended, restarting Visual Studio fixes the problem but the best solution I've found so far is to start Visual Studio without a solution, open Debug -> Attach to Process, change the Connection Target to the remove server and wait for the process list to load. Then Cancel, do not attach yet. Load your desired solution and then come back to Attach to Process and the remote process list will still be loaded. Connect to your desired process and everything should work properly from then on.
I'm happily in the middle of coding then I try to launch my app in debug mode but I get this error message.
Unable to activate Windows Store app
This app failed to launch because of an issue with its license
The app was launching fine a few minutes earlier so this came as a surprise. I tried restarting Visual Studio but doing so did not help.
I got the annoying "renew your developer license" dialog yesterday I think. It had renewed without issue.
How do I make this error message go away so i can debug my app?
Well, I got it working by deleting the main project's 'bin' and 'obj' folders. Cleaning and Rebuilding wasn't enough. Hope this answer saves someone else the few minutes of confusion I just experienced.
I recently had a similar issue. In my case I had to uninstall the re-install the app to get it working.
Hope this helps someone. Also, to find out further detail about why it failed, you can checkout the event logs:
Event Viewer > Applications and Services logs > Microsoft > Windows > Aps > Microsoft-Windows-TWinUI/Operational
There might be some more detail in there. In my case it was logged as an error event which said the app could not be launched because of a temporary issue with its license.
I just uninstalled the existing version of the app from the start screen, and then launched the app again from Visual Studio and it is launched just fine.
I think the reason behind this is because of renewing the license of Visual Studio and trying to launch an app that was installed when the previous license was active.
I see doing stuff with the bin and obj folders appears to be the accepted answer to this.
I fixed this issue by selecting the 'Uninstall and then re-install my package. All information about the application state is deleted.' check box under the Debug tab of the project properties. You can uncheck it once you've done it once for all future builds.
I haven't had any issue with this solution. Simple fix and you don't have to worry about someone doing something to folders that could cause bigger issues.
http://daxdude.blogspot.com/2013/04/c-error-unable-to-activate-windows.html
I've had this issue a few times now, most of the time deleting the Bin and Obj folders will clear the issue up (These folders are automatically generated during a project build so don't worry about deleting them)
I have found whilst debugging on a remote device (A tablet or phone) that Deleting these folders doesn't solve the problem though - in this case the best solution I have found is just to do a restart on the device I was remote debugging to.
Simple but it works!
I just cleaned my solution and re-started Visual Studio. That did the trick for me - and didn't involve hunting around for files to delete, so you might want to try that first.
go to BUILD-->Clean Solution and click and after its has been cleaned again go to BUILD-->Rebuild Solution. After it has successfully rebuilt your solution just deploy it(Ctrl+F5). This solved the problem for me.
I've just installed the Visual Studio 2012 RTM on a Windows 7 x64 desktop.
Unfortunately, I'm very underwelmed by the performance of the out-of-the-box installation. Everytime I try to rename a file in the solution explorer, change to a MVC cshtml editor, open a designer view, or intellisense pops up when I start typing with the c# editor, the whole visual studio applications hangs for 5-10 seconds.
There are no customizations, plugins, extensions enabled here that do not get applied with the standard installation.
Has anyone else experienced this? Has anyone else found a way to log the application faults which occur, or detect the hang. I need some way to determine what is going wrong, in order to identify what needs to be altered to rectify the installation.
The problem is you are consuming the lot more resources of the system which is causing hung state of VS. Please close any of other application who is using more RAM. You can take the help of Task Manager to close those application. Please keep in mind if you are running SQL standalone database instance services then its also causes the hand issue. The best is keep you system free from running unuseful application or Go for System upgrade. :-)
I've written what should be a very simple unit test using the Native Unit Test project in Visual Studio 2011 Beta. The test builds and fails (not unexpectedly), and I need to debug it. When I try to launch the test under the debugger, the debugger never starts, and instead presents this dialog which lingers indefinitely:
Anyone know what might cause this? I've never had this problem with previous versions of Visual Studio.
Update:
I've opened an MSDN thread on this: http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/db3213f8-9658-4470-9e3f-3b67ec954fae
I also opened a connect bug (which apparently was just summarily dismissed): https://connect.microsoft.com/VisualStudio/feedback/details/735369/debugger-wont-start-for-native-unit-test#details
I would need to know some more information regarding this issue but it seems like it is possible that the DebugAttachProcess() method in windows isn't returning which can happen in the case that you do not have enough permissions to do so... make sure you run VS as Administrator, also, you can try to debug it in ollydbg to see if it is an executable problem, although it wont give you the source (you're stuck in assembly).
and thank you for your time.
I am using Titanium Appcelerator to write an app for Android, and as compared to Windows, where the emulator was quite stable, in Linux I get the following symptoms:
emulator restart with no reason, sometimes after a runtime error, sometimes right after launching my app, and sometimes just right after booting completely after being launched
emulator informs that "process $1 is not responding", where $1 is generally the system process, but sometimes may be acore, or the calendar. This may happen while installing my app on the emulator, right after loading it, or right after unlocking the screen.
As it is easy to imagine, testing code like this can be quite difficult, so I was wondering, has anyone else stumbled upon this problem, and/or know how it could be solved?
Thank you very much in advance, and pls let me know of any info I should provide.
Leo
You should verify that the emulator is working fine without Appcelerator first. Definitely update to the latest SDK (r8) and create a new emulator AVD and see if the problem is there without Appcelerator.
I think I found a solution, but I don't claim it is universally valid: I just erased the virtual device created under Titanium, changed the project file for it to use SDK 1.4.2, and had it launched again under 1.4.2. It certainly didn't build my app, but at least it created a new virtual device, which I use now to build against 1.5.0, working like a charm so far.
Thanks again Manfred for pointing me in the right direction!