I am testing an application which loads a powerpoint (.ppt or .pptx) file insert it. Application gives same look an feel like powerpoint with some extra setting when the file is loaded inside the application. When I try to automate the application, I click a button to load the powerpoint file into the application. After the loading process white framework fails to continue playback.
When I restart the same test again I got "NonComVisibleBaseClass was detected" exception.
I can only continue my testing after restarting the entire application. Does anyone face this kind of issue? your answers will really helpful to continue my testing.
It's known issue.
http://social.msdn.microsoft.com/Forums/en-US/27c3bae8-41fe-4db4-8022-e27d333f714e/noncomvisiblebaseclass-was-detected?forum=Vsexpressvb
Navigate to Debug->Exceptions...
Expand "Managed Debugging Assistants"
Uncheck the NonComVisibleBaseClass Thrown option.
Click [Ok]
I stumbled upon this page after having the same problem. Although I'm not sure this solution may help you it helped me and maybe can be useful to someone else.
My WPF application needed to run with elevated privileges and if I tried to run VS without elevated privileges my tests broke with the aforementioned error. What I did was simply restar VS as Administrator and the tests started working.
One thing I noticed was that when I was running without elevated privileges the Window.Framework was 'Win32' and the Window.Items was empty. After running VS as Administrator The Framework propery was 'Wpf' and the Items list was filled correctly. I don't know what is the real cause of the problem here. But it worked for me and maybe it'll work for someone else.
Related
Did anyone encounter an error with ASP.NET debugging? I've made a really simple, empty MVC page, I've tried returning /Home/Index.cshtml and a string, and each time I get a windows jingle and the browser can't find the server. It doesn't happen when I run it without debugging though, then the website runs just fine.
I've also tried the default MVC template, with Bootstrap etc, and it's the same - runs without debugging, doesn't run with debugging.
It's probably important: I'm running Visual Studio 2017 on up-to-date Windows 10. I've reinstalled the system several weeks ago, really wouldn't want to do that again :/
Generally we could debug an app with the normal user, but sometimes we need to use the admin, for example, as far as I know, if we want to use the attach to process tool for remote debugging, we often run the VS as the admin or others.
This document share us the tasks we need administrator permissions to completeļ¼
https://msdn.microsoft.com/en-us/library/jj662724.aspx?f=255&MSPPError=-2147217396
If possible, you could refer to it especially "Debugging" area in above link.
Hope it could help you:)
I have a problem debugging a web forms application that is configured to use IIS for debugging, under Windows 7 and Visual Studio 2010. An example has just occurred, where I make a change to the code behind for a web form, save, and apparently rebuild before starting the app using F5.
The app starts, and I get an error message trying to do something in the app. I tell the debugger to break when an exception is thrown and try my task again, only to be told
The source file is different from when the module was built.
where the module is C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\9d7b45ca\11a98b19\assembly\dl3\5e6cf0b2\636409d4_dfeecb01\PerfixEMS_Admin.DLL
The physical folder for my test web site is set to the web application project's source folder, so I have always assumed that IIS will look in the bin folder for required assemblies, and these will be rebuilt as expected. Why is this not happening?
Cleaning the solution usually works for me.
Update
Given the high number (320) of projects I understand why Clean and Build won't work for you. You should however try it at least once to see if fixes things.
If it does fix your problem but doesn't last you'll need to do one of two things.
Clean just the one file
Delete the offending temp file. You probably won't be able to do this because with VS running since it may have a lock on the DLL. You may also have to stop IIS. You can use Process Explorer to look for the processes that have a lock.
Use a custom solution
Its unlikely that you're going to be modifing all 320 projects at the same time. Create a custom solution for just the projects you're working on. You'll still be able to step through any project you have the DLL and PDB for if you need to.
Which to do
Using a custom solution has its problems since you can no longer use project reference for projects not in your solution. This impacts your team's source control. You'll also have to make sure the DLL's and PDB's from outside your solution are in a stable location and you'll need a way to detect when thoes other projects have changes that you care about.
These problems can be overcome with a careful check-in process for Project changes and scripts that copy files and working with team members to figure out how to communicate changes.
On the other hand closing VS for every change or running Clean and build isn't really tennable either.
it may be a workaround, but I just need to see if it will work or not, then we may investigate more in the original case. but for now, try this:
1- publish this website to a different folder
2- open the newly published version from your preferred browser (ex: http://localhost/APP_NAME).
3- from VS, open "Debug" menu, choose "Attach to process..."
4- select the IIS worker process "w3wp.exe" and click "Attach".
(if you can't find it, make sure that the checkbox "show processes in all sessions" is checked)
5- start debugging your source code normally and let me know what happened, thanks.
My company gave me a web application project and I went to debug it and set some breakpoints and they dont fire. I am using Response.Write all over the place to debug. Anyone know what maybe going on?
I am running the application off my localhost I was pushing F5, but since the breakpoints dont hit by making changes and adding Response.Write statements and clicking save then refreshing my browser I get the changes for whatever reason.
Hovering over the breakpoint it says "The breakpoint will not currently be hit the source code differs from the original version"
Another tidbit is I created a new web application project and created a breakpoint and it works, its only specific to this application it seems like, but dont know what it could be?
Hovering over the breakpoint it says "The breakpoint will not currently be hit the source code differs from the original version"
Try this:
Close Visual Studio and make sure any instances of ASP.NET development server are closed as well
Delete everything from "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files" (where v4.0.30319 is the version of your .NET Framework)
Definitely need more info, but I would check that your are building with debugging symbols to cover the dumb stuff.
Okay, after reading the comments posted on your question I was making the following assumptions.
You are running using the built in VS development server
You are compiling in debug mode
You've set debugging true in your web.config
I've seen this problem before and for me it's been resolved by restarting Visual Studio.
Assuming that you are running on IIS on the same machine that you have visual studio installed:
Have you attached to the application pool process
Is you code the same as what is deploy? (Is the latest version deployed)
Are you logged in as administrator?
Are you running visual studio as administrator?
Just to make sure, you are running in debug mode?
I ran into this problem a while ago as well, instead of using response.write, you could try outputting the data to a label control's text value instead to see the values of your code.
It's a bit of a sloppy work around, but I couldn't figure out why that one particular project I was working on didn't let me debug it.
This problem is, for me, mostly caused by a mismatch of the loaded dll files (symbols) by webserver, and those that the project are pointing to when you try to breakpoint. It's different files. I have located different causes. One could be a simple hang-up by webdev instans (force shutdown. But also that there occur some kind of mismatch if you got different compilation methods between project within same solution as the web project.
This desc may not be your exact problem, but perhaps it will lead you into right direction. I find this often being a dirty unlogic error that just are irritating (but also completely fixable without data loss or reconfiguring, when u understand the trick).
I had the same problem, and it turned out only Internet Explorer works with debugging and breakpoints. To avoid having IE as my default browser, I changed the launch settings in the .Web project to run IE with the path as command line parameters.
I have an puzzling problem. I have a new ASP.NET web application in VS2005 that runs fairly well, but I am having a problem and would like to set a break point to see what is going on. I have compiled the project in Debug mode. I have debug=true set in the web.config. But it appears that the IDE is not attaching to the process at all. Have I overlooked something? I am using the development server and not IIS. This has never been a problem in the past, but is this time.
Have I overlooked anything? Thanks for any help.
Rob
I had this issue a while back with VS2005. I don't remember where I got the following instructions from (copied them to a file which I'm now copying to you) but doing the following steps worked for me. It has something to do with IE8 attaching itself to multiple processes and messing up the debugger. Word of warning, this has you editing the registry, so use at your own risk / take all your normal precautions, etc.
Open RegEdit
Go to HKEY_LOCALMACHINE -> SOFTWARE -> Microsoft -> Internet
Explorer -> Main
Add a dword under this key called TabProcGrowth
Set TabProcGrowth to 0
If you run into the same problem on
Vista or newer, you will also need to
turn off protected mode.
Please note also that I was/am running XP at the time, so I did not have to use the "Vista or newer" clause there. No idea if that has any adverse effects either.
Sorry if I am stating the obvious, but you need to Start Debugging <F5> rather than just running the executable after compiling. Are you doing this?
If you don't hit the breakpoint, you are either not debugging (F5) or your code isn't reached at all. If you want to know which of the two is happening you can throw an exception right at the code where your breakpoint is. If your application is failing at the exception, you know you are not running it with the debugger. If it doesn't fail at the exception you are simply not reaching that piece of code and you will have to look harder for which code you are actually running.
throw new Exception("if I see this exception, I am not running the debugger");
Or maybe you are running two instances of the development server. I've had that sometimes. Look in the Windows system tray for the icon. If you see two (or more) you can right click to stop them and restart debugging.
Working on an ASP.NET Project (not Web Site) and trying to Start without Debugging from Visual Studio.
First this:
alt text http://uploadimages.epiforge.com/Crash.png
Then this:
alt text http://uploadimages.epiforge.com/Burn.png
Once completely reinstalled Microsoft Visual Studio 2008 and it was fixed... for a while.
Looking for any information I can find, including:
What in the Hell is going on?
What way is there to fix it other than completely reinstalling VS2008?
How can it just be fixed permanently?
Try this - shouldn't take more than a minute or two.
Create a brand-spanking-new, empty Web Application Project. Enter something like "hello world" on the default.aspx page. Run it.
If your problem disappears, you've got something (3rd party DLL, etc) referenced in your project causing the issue.
Else, your looking at an OS, IDE or other environmental issue. I've had some odd VS issues in the past on Win7 that were solved by available updates. I still have to run VS as an administrator to use the "attach to process" for debugging.
update
So, the new project works, which tells us that the problem is somewhere in your old project. This is where the fun part starts, which is what I like to call "binary search debugging." It's crude, a pain in the ass, and if your app is pretty complex, sorting out dependencies can be a pain in the ass.
Create a new project and add all of your source to it.
Build, run. Did it work?
No? Remove half of the source.
Build. run. Did it work?
If so, the problem is in the half that you removed.
Else, it's in the half that remains.
Now, I know this is an incredibly naive approach to debugging, and its very brute-force, and some app configurations can make this damn near impossible, but at least its straightforward.
Any other service listening to the port number you're using? Try changing the port number or use IIS instead of running it on cassini.