When you compile a SharePoint solution, it deploys to the SharePoint
server and a debugger attaches to debug it. The process used to debug
the solution depends on the setting of the Sandboxed Solution property:
sandboxed solution or farm solution.
Farm solutions, which are hosted in the IIS worker
process (W3WP.exe), run code that can affect the whole farm. When you
debug a SharePoint project whose Sandboxed Solution property is set to
"farm solution," the system's IIS application pool recycles before
SharePoint retracts or deploys the feature so as to release any files
locked by the IIS worker process. Only the IIS application pool serving
the SharePoint project's site URL is recycled.
Sandboxed solutions, which are hosted in the SharePoint
user code solution worker process (SPUCWorkerProcess.exe), run code that
can only affect the site collection of the solution. Because sandboxed
solutions do not run in the IIS worker process, neither the IIS
application pool nor the IIS server must restart. Visual Studio attaches
the debugger to the SPUCWorkerProcess process that the SPUserCodeV4
service in SharePoint automatically triggers and controls. It is not
necessary for the SPUCWorkerProcess process to recycle to load the
latest version of the solution.
With either solution type, Visual Studio also attaches
the debugger to the browser to enable client-side script debugging.
Visual Studio uses the script debugging engine for this purpose. To
enable script debugging, you must change the default browser settings
when you are prompted.
Visual Studio attaches the debugger only to the W3WP or SPUCWorkerProcess processes running the current site. Visual Studio also attaches the managed COM Plus and workflow debugging engines.
Visual Studio attaches the debugger only to the W3WP or SPUCWorkerProcess processes running the current site. Visual Studio also attaches the managed COM Plus and workflow debugging engines.
No comments:
Post a Comment