If more than one person is debugging, each person must enter debug properties manually. Visual Basic and C# projects store the debugging properties in a user-specific file ( or ), and this file is not under source control. Source controlĭebug properties are not shared among multiple users under source control. If you want to use command-line arguments when you start debugging, you must select a Start Action other than Start Project. If the Start Action on the Debug property page is set to Start Project, Visual Studio does not use command-line arguments when debugging the project, even if you have specified command-line arguments as start options. For more information, see Just-In-Time debugging in Visual Studio. You can also use Try.Catch statements around your methods to catch exceptions.īy default, Visual Studio also does not display Just-In-Time debugging errors for Office projects however, you can enable this feature so that you can see the errors that are raised. These msosec exceptions will not affect your solution. Errors referring to msosec not being found appear in every project, but are safe to ignore.
If you set the debugger to break on common language runtime exceptions, all exceptions will now break into the debugger, including ones that you have handled and some first-chance exceptions from the runtime itself, which might not be relevant to your project. For more information, see Manage exceptions with the debugger. To see these errors, set the debugger to break on common language runtime exceptions. For example, if a VSTO Add-in created by using Office development tools in Visual Studio throws an exception, the Microsoft Office application continues without displaying an error.
All word documents open debugger code#
Display exceptionsīecause of the way that managed code interacts with unmanaged code, Visual Studio does not display errors that are thrown by Microsoft Office applications. However, during debugging, F10 and F11 do have the same functions as in Visual Basic and C# projects. In Visual Basic or C# projects, the debugger stops on the main function in Office projects, Visual Studio does not have control over the Office application's main function. When you start debugging an Office project, F10 and F11 do not have the same behavior as when you start debugging other Visual Basic or C# projects. Then, browse to the location of the appropriate Office application executable. If you want to debug your VSTO Add-in by using a different version of Office (2013 or 2016), open the Project Designer, and in the Debug tab, choose the Start external program option button. If you're using Visual Studio 2013, Visual Studio starts Office 2013. If you're using Visual Studio 2015, and you have both versions of Office installed side-by-side, Visual Studio starts Office 2016. Debug Office 2013 VSTO Add-ins by using either Office 2013 or Office 2016 However, any macros that were stored in the Normal template are not recreated. If this happens, you can delete the corrupted Normal template and it will automatically be recreated the next time you open Word. If you are debugging a document-level customization for Word, repeatedly stopping the debugger and causing Word to close suddenly can lead to the Normal template becoming corrupted. You can also detach from the process first if you still want to work with an open document or worksheet after stopping the debugger.
Typically, it is better to detach from the process before stopping the debugger, so that you can quit the Office application in the normal way.
This might include all documents or workbooks that are opened while the debugger is running. All other documents that are opened in the terminated Office application process are also closed without warning, and any unsaved changes are lost.
When you stop the debugger, the debugger terminates the application process abruptly, or detaches if you have the debugger set to detach. When you start debugging a document-level project, the document or workbook opens in a new Word or Excel process. When you start debugging a VSTO Add-in project, a new process for the targeted Office application is started and the VSTO Add-in is loaded. You can start debugging an Office project just like you start debugging other Visual Studio projects for example, you can press the F5 key. Office Add-ins have a small footprint compared to VSTO Add-ins and solutions, and you can build them by using almost any web programming technology, such as HTML5, JavaScript, CSS3, and XML. Interested in developing solutions that extend the Office experience across multiple platforms? Check out the new Office Add-ins model.
0 kommentar(er)
