I've been trying to determine why w3wp.exe process in my Attach to Process dialog box in VS08 is missing "Script" type in the list?
AttachToProcessVS2008printscreen
This seems to prevent me from debugging classic asp pages. Can you please advise how to 'add' "Script" to w3wp.exe process? I am assuming this is IIS. I am running on Windows 10.
Related
I am trying to debug .asp pages by Attaching to w3wp.exe, but my breakpoints do not get hit.
I have "Enable Client-side Debugging" & "Enable Server-side Debugging" & "Send Errors to Browser" all set to "True" on machine level, Default Website level, and website level.
For my application, I am using DefaultAppPool, which is v2.0 .NET CLR Version, Classic Managed Pipeline Mode, NetworkService Identity, and has Enable 32-bit Applications set to "True".
When I launch my website and go to "Attach to Process", w3wp.exe shows with "NETWORK SERVICE" User Name and "T-SQL, Managed, x86" Type. Sometimes I also see it showing just "x86" for the Type column, but I never saw it showing "Script" in the Type column (even though in "Attach to" window, I always keep "Script" or "Script" & "T-SQL" checked.
Please advise.
I thought I'd give SharePoint development a go, to broaden my understanding of Microsoft technologies and ran into a situation I refuse to understand.
I have a new web application created: http://localhost:11523 and set up the site collection as required. I can browse to the web site fine, without any issues, but now I want to start developing against this, using the object model.
Right, so after I struggled with SPSite site = new SPSite("http://localhost:11523"); I figured that I'm not running VS2008 in elevated permissions, so restarting VS I finally got one step further.
Whenever I step into my code, I get:
The Web application at
http://localhost:11523/ could not be
found.
I've Googled this without luck. The application is most definitely there, I can browse it, add web parts and go mad. I just can't seem to connect to it via Visual Studio.
Any ideas would be great.
EDIT
I thought I'd isolate my method, called "GetListFromSharePoint(string name)" into a test method (nUnit Framework) and to my surprise returned 9 entries from the list, as expected. When I dumped the method back into my web application (not SharePoint, trying to test the Composite Control through a normal Web site), and run into the mentioned problem.
This is in SharePoint 2007, and I'm developing on the same machine onto which SharePoint 2007 is installed.
This approach used to work, for some reason, I just can't get it to recognize SharePoint. The test stubs work find, just not the web application.
Edit 2
So there where a couple of things I "missed", which kind of solved the problem by itself.
Firstly, I was developing on a x64 Windows 2008 box, thus SharePoint 2007 was running in x64 mode. Cassini, turns out, is 32bit regardless of the platform you run it on, which caused some compiler bugs (I did not have IA64 compilers installed). After installing this, I figured out that the default web site (localhost:80) had been disabled by SharePoint.
Renabling the default web site, allowed me to create my web application as a virtual directory against it, which allowed my debugger compiler to run in x64.
My next challenge was access permissions. Because any new virtual directory on port 80 is assigned to the default application pool, is it assumed that the user does not have the right permissions, so I had to change my web application to run under my SharePoint web application's application pool.
The last thing I had to do was run my SharePoint code with elevated permissions.
Working like a charm :D
Note! Enable debug on your SharePoint web application....
Thanks,
Eric
(You have not specified version - assuming SharePoint 2010).
You need to decide what object model you want to use:
client (to be able to access the server from any other machine)
server (the one that you are trying now, can only be run locally).
Most likley reasons your code not work:
using "localhost" instead of ""computer name" in the Url. (I believe it is the reason.)
you are running your code not on the same machine as the SharePoint
you are running code under non-admin account
Check out how sites collections are configured in "Central Administration" site - urls associated with each site collection are listed there - make sure you are using correct one.
You can also try enumerating all site collections in SPWebApplication (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebapplication.sites.aspx) to start expiriments.
I dont think the SPSite connect through the IIS, and if SharePoint isn't set up to respond to localhost (done in the Central Administration) you wont be able to connect to that url. IIS works a bit different here since it relays the signals to "localhost" to the "web application instance".
Start by checking in your SharePoint Central Administration. Go to "Configure alternate access mappings" in the "System Settings" section. Here you have your SharePoint instances, there are three properties which you can see directly in the list; 'Internal URL', 'Zone' and 'Public URL for Zone'.
If the Internal URL isn't set to Localhost you wont be able to use that connection you suggested. It bay be improper to change this to another url as well, so simply try to set your SPSite site = new SPSite("http://yourinternalurl:11523"); to whatever's in that box! :)
Cheers
I'm getting the following error while trying to create a SPSite instance (not open it, just create it):
"The Web application at <URL> could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application."
I have SharePoint Foundation 2010 installed on x64 Windows 7 laptop and VS 2008. I've done a lot of searching the last couple of days and I've tried any suggestion there is:
Setting user permissions to the database.
Targeting the application for x64 CPU.
Running my app with the sharepoint app pool account. Creating new app pool.
Creating windows forms and console applications to run the code from there.
Adding and removing the web application administrators.
Checked the logs (nothing in there).
Writing the URL in full, with machine name and with IP.
The funny thing is that the same code was working fine at one point and then just stopped. I cannot recall to have done anything special to damage it.
Any help will be much appreciated.
Regards,
Martin
To answer my own question the sharepoint site had to be on the default port - 80. Publishing it on any other port and trying to access it by putting the port in the URL did not work. Strange but it worked.
I wrote a custom web part for SharePoint 2007 that loads an existing user control. One of the things the user control does is an asynchronous upload of a file via FTP. I'm using a third-party FTP library that has BeginUpload/EndUpload methods for async file transfer. I also have an update panel in the user control that I use to display a running total of the number of bytes that have been transferred, based on an event raised by the FTP library. I've added all the necessary AJAX settings to web.config.
Everything works great if I run the user control by itself from a separate project. But when I access the web part that hosts the control and try an upload, the FTP library transfers about 64 KB and then the thread it's running on dies. The message I get in the VS output window is:
The thread 'Win32 Thread' (0xf34) has exited with code 0 (0x0).
I get several of those and then the FTP library throws an exception (basically it times out), the IIS worker processes blow up, and the whole thing comes to a halt. Is there something special I need to do in my SharePoint configuration or the web part to make this work? It seems to be something about SharePoint since the same code works fine if SP is out of the picture.
I submitted this problem to Microsoft SharePoint developer support and they were able to reproduce the error with the FTP library I'm using, which comes from ComponentSpace. Normally what I'm trying to do is possible, but for some reason it just didn't want to work.
Their solution was to save the file on the web server by doing a Request.Files(0).SaveAs and then doing the FTP upload. Not ideal, but it gives me the progress indicators I wanted.
Chris Tybur, I have tried their FTP component and found many bugs. I would not recommend ComponentSpace's FTP
Previously our SharePoint server was 32-bit and we used the web capture web part to display a bugzilla search results page. Since we've migrated to a 64-bit server the webpart no longer works. We're running the same versions of everything, the only change was moving from a Windows Server 2003 32-bit box to a Windows Server 2003 64-bit box.
Oddly enough, the logs don't contain anything. The pages where the webparts appear are the only place that error messages appear. Here is what I have:
-Web Part Error: A Web Part or Web Form Control on this Page cannot be displayed or imported. The type could not be found or it is not registered as safe.
Error - An unexpected error has been encountered in this Web Part.
The reason I suspect the 64bit vs 32bit issue is that I saw numerous posts on the subject in various forums. It would appear that I am not the only one with this issue and all the troubleshooting has lead to this conclusion.
In all the times I have come across an error in changing from 64bit to 32bit, the change in the number of bits is usually a red herring and the actual cause of the failure is something else.
Check the sharepoint logs for the WebPart errors. They will help show exactly what is wrong.
Post the relevant errors if you still need help.
What is the 'web capture web part'? If it isn't an out of the box web part that message makes perfect sense.. you'll need to install that web part.
Actually it might be something out of SharePoint 2003.. see Web Capture in SharePoint 2007