I am trying to see the raw response message returned from a call to an internet-connected web API. The calling code looks like this:
object[] results = this.Invoke("MethodName", new object[] { requestObject });
The problem is that while debugging, the results variable already appears completely deserialized, for example the date property I'm interested in is already a DateTime type.
So I did the following:
Turned off "Enable Just My Code".
Turned on "Enable .Net Framework source stepping".
Enabled symbol loading and ensured that the System.Web.Services module has had symbols loaded ("Symbols loaded."):
System.Web.Services.dll
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Web.Services\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Web.Services.dll
C:\Users\user\AppData\Local\Temp\SymbolCache\System.Web.Services.pdb\312122031d1b4f30b59771eb845018121\System.Web.Services.pdb
I dropped a breakpoint inside of the following method starting on line 163 of SoapHttpClientProtocol.cs (the one called by my client code):
protected object[] Invoke(string methodName, object[] parameters)
I started debugging the project and used my UI to trigger the code that makes the request. When I get to the Invoke line above and press F11, it tries to remote debug and step into the remote server:
Microsoft Visual Studio
Unable to automatically step into the server. Connecting to the server machine 'api.example.com' failed. The Visual Studio 2015 Remote Debugger (MSVSMON.EXE) does not appear to be running on the remote computer. This may be because a firewall is preventing communication to the remote computer. Please see Help for assistance on configuring remote debugging.
Note: I have no desire to do remote debugging, I just want to step into the .Net code.
After hitting OK, it goes to the next line in my client code without either stepping into the .Net library or hitting my breakpoint.
When I look at the breakpoint in break mode (instruction pointer still on line after the calling Invoke line), it is a hollow circle and says "This breakpoint will not currently be hit. No symbols have been loaded for this document."
This makes no sense as the symbols have been loaded, as proven above.
How do I either step into the .Net source code, or perform this request via another means? This particular request is a bit more complicated than some, as it requires a certificate (.pfx file) as well as a username and password.
Hmmmmm... one data point is that the breakpoint I dropped is in a file which says at the top:
// Decompiled with JetBrains decompiler
// Type: System.Web.Services.Protocols.SoapHttpClientProtocol
// Assembly: System.Web.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
// MVID: A6D697F9-972E-41EC-820F-E59621A808B5
// Assembly location: C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Web.Services.dll
It suddenly seems to me that this is where the discrepancy may be coming from. Is JetBrains interfering with my stepping into .Net source?
Unable to automatically step into the server. Connecting to the server machine 'api.example.com' failed. The Visual Studio 2015 Remote Debugger (MSVSMON.EXE) does not appear to be running on the remote computer. This may be because a firewall is preventing communication to the remote computer.
So actually you just debug your web app locally, but you got the remote debugging error/warning, am I right?
Like this document here:
https://msdn.microsoft.com/en-us/library/ms164726.aspx?f=255&MSPPError=-2147217396
If you are getting this message while you are debugging locally, your anti-virus software or a third-party firewall may be to blame. Visual Studio is a 32-bit application, so it uses the 64-bit version of the remote debugger to debug 64-bit applications. The two processes communicate using the local network within the local computer. No traffic leaves the computer, but it is possible that third party security software may block the communication.
In addition, you use the correct steps to debug the .NET Framework source code after your discussions:
But if you use the VS2015, you need to think about that whether the Reference source has been updated for the .NET framework:
Cannot step into .NET framework source code
A user voice here:
https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/6886255-please-keep-the-reference-source-symbol-server-upd
Related
I want to publish to IIS the source code of my website (visual studio 2017 web forms website in vb.net or c#) without pre-compiling the project, so I can modify the source code directly on the server with IIS.
I know this is possible, I have done it in the past, and I have seen it done even now, but I cannot figure out what I need to do for this.
When I copy all the website source code to the server with the IIS, the website does not run... any ideas? or where to look for an answer? Is it a matter of setup? of the type of project?
When I call the website I get the following error:
Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.
Parser Error Message: The CodeDom provider type
"Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider,
Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" could not be
located.
Source Error:
An application error occurred on the server. The current custom error
settings for this application prevent the details of the application
error from being viewed remotely (for security reasons). It could,
however, be viewed by browsers running on the local server machine.
Thanks!
#Gabe Thanks for the directions:
File - New Project, I see it under Visual Basic/Visual C# - Web - Previous Versions (ASP.NET Web Forms Site)
I tried it, and it works just fine! Basically if you create a project like you describe, you can just copy the source code in a server, without even installing visual studio there, and you can develop the site directly there.
This is ideal when you want to test things directly with external users, test things directly on the live or test servers, and of course you can make sure you have the source code of the project running, without having to keep both the source code and the compiled version.
There are a few drawbacks though:
1) you disrupt the website when you change things, and the application pool is restarted whenever there are changes, users in sessions are kicked out, etc...
2) there is a small delay while the site gets recompiled
3) there are cases where if while the code gets recompiled there are users online, there is asp.net corruption
Thanks for the replies!!
Regards
Manos
I have a problem when I published web application in IIS
sometimes the WorkBook.SaveAs method works fine, sometimes not.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Runtime.InteropServices.COMException: The remote procedure call failed. (Exception from HRESULT: 0x800706BE)
Source Error:
workbook.Saved = True
workbook.SaveAs(Server.MapPath("~/MyFolder/Excel.xlsx"))
workbook.Close()
APP.Quit()
and sometimes the error is on APP.Quit
Well the first thing to note, is that office interop is not supported server side by Microsoft, due to both licensing and stability/reliability issues:
Microsoft does not currently recommend, and does not support,
Automation of Microsoft Office applications from any unattended,
non-interactive client application or component (including ASP,
ASP.NET, DCOM, and NT Services), because Office may exhibit unstable
behavior and/or deadlock when Office is run in this environment.
Still, many people do this/try to do this, and run into similar problems as you did. Generally this appears to be caused by permission issues (security context and the DCOM security configuration). For which different potential solutions have been described, such as
How to make IIS7 play nice with Office Interop With a 2 different solutions, one of which is mentioned several times elsewhere:
Open Windows Explorer
Depending on whether you installed a 32bit or
64bit version of office you will need to do one (or both) of the
following:
32bit Office installation: Navigate to
C:\Windows\System32\config\systemprofile
64bit Office installation:
Navigate to C:\Windows\SysWOW64\config\systemprofile
Verify the folder
"Desktop" exists (create it if it's not there)
Right click > Properties
On the security tab: Add the account under which the site
is running (eg: Network Service) with default permissions (Read &
execute; List folder contents; Read)
RPC failure opening an excel document. Listing the following solution:
Type Dcomcnfg.exe in Run which opens the dcomconfig utility.
In the dcomconfig utility,
go to Component Services --> Computers --> My Computer --> DCom Config
--> Microsoft Excel Application (and Powerpoint)
Right click it and go to properties. Go to security tab. Under
Security
1) Launch & Activation Permissions --> Choose customise and click
Edit. Add User Network Service and check everything under Allow for
it.
2) Do the same for Access Permissions and Configuration Permissions.
Then click Apply and close everything.
Another one using Windows Server 2003, with a different solution
It turns out that there was some kind of permission that the COM
Object needed. Setting the AppPool (for the site) on the Win2003
server to "SYSTEM" fixed the problem. For some reasion (by Default)
the ASPNET account has permission to whatever the COM object was
trying to access.
Perhaps one of these solutions will work for you.
The reason it sometimes works for you and not other times, may be related to the contents of the specific excel file, e.g. whether it contains any VBA scripts or references any (specific) modules. So that is something you should look into.
I've been trying to install the new Microsoft Release Management app that has just been released to MSDN and am having issues
It consists of a server side component for TFS 2013, and a client side component for VS2013
The server side component runs through and says that it is installed fine, but then i can't seem to connect the client side part up to it
After a bit of investigation it seems that the web services site that is installed on the server side is not working properly
It is installed on a Windows 2012 box that is also running TFS 2013, SQL 2012, and SharePoint 2013
If i browse to the newly created ReleaseManagement website I get a 503 (Service Unavailable) message.
I checked out IIS and the app pool had stopped
in the application event log I could see a load of messages saying "current configuration only supports loading images for x86 processor architectures"
I thought this was possibly to do with the "Enable 32-bit Applications" option in the IIS app pool (was set to FALSE)
I changed that to true and tried the site again. This time the app pool doesn't crash, but I get ASP.NET errors stating "Could not load file or assembly 'Interop.ActiveDs' or one of its dependencies. An attempt was made to load a program with an incorrect format."
Has anyone managed to install this yet? Any ideas on what's going wrong here?
I know it's very new, but I'm struggling to find much information about the product at all
Thanks a lot
Here is a link towards some documentation regarding this problem. As pointed out in the comments, it is related to a bug caused by SharePoint: http://support.inreleasesoftware.com/entries/24794668
Interesting section:
The request failed with HTTP status 503: Service Unavailable.
This error message usually means that the InReleaseAppPool application
pool is stopped. Please ensure that it is started. If the application
pool stops after some time by itself, it might be due to a bug caused
by SharePoint 2013. Validate your problem by looking at the Event
Viewer. Confirm that your error is similar to the following:
Event Log Error Event ID 2282
The Module DLL 'C:\Program Files\Common Files\Microsoft Shared\Web
Server Extensions\15\isapi\spnativerequestmodule.dll' could not be
loaded due to a configuration problem. The current configuration only
supports loading images built for a x86 processor architecture. The
data field contains the error number. To learn more about this issue,
including how to troubleshooting this kind of processor architecture
mismatch error, see http://go.microsoft.com/fwlink/?LinkId=29349.
We can apply a quick fix using this command
appcmd.exe set config -section:system.webServer/globalModules
/[name='SPNativeRequestModule'].preCondition:integratedMode,bitness64
Or you can manually enter the preCondition entry in the
ApplicationHost.config file
More information can be found here:
http://blogs.flexnetconsult.co.uk/colinbyrne/2012/11/11/RunningA32bitApplicationAlongsideSharePoint2013Problems.aspx
FIX:
the user which you specified to run the TFS service needs "log on as a service" and "Log on as batch job" permissions. I've set that up via GPO.
This solution worked for me. I execute this command
appcmd.exe set config -section:system.webServer/globalModule/[name='SPNativeRequestModule'].preCondition:integratedMode,bitness64
in C:\Windows\System32\inetsrv and C:\Windows\System64\inetsrv.
Got some strange problem.
I'm developing some complicated Web Services network that uses some VB6 .dll. In my previous post I got some problems with the dll but we've solved them.
So, the new problem is:
When I debug my service (those which uses VB6 dll) on development server from visual studio - everything works fine, the problem starts when I publish my service on IIS (I tried my local IIS). After that, when I call .dll method (as I understand I need to call it by reference - and that's what the compiler tells me) I got an exception:
"System.Runtime.InteropServices.COMException (0x800A000D): Type mismatch at ..."
Actually is happens here in the third line:
Object s = (Object)OrderId;
Object s1 = (Object)lines.Length;
proxy.OrderRead(ref s, ref s1);
OrderId and Legth are integers.
As I understant this is exception that comes from the .dll from vb6 :/
What the problem may be? Why it runs when debugging but fails on IIS?
When debugging in vb6,the IDE will register the dll for you. After publishing, have you may ahve to register your vb6 dll on the server. Open a command prompt and change to the location of the dll and run regsvr32 myvb6.dll.
Also, check these settings.
http://support.microsoft.com/kb/281630
So, I've read that it is not a good idea to install VS2008 on my test server machine as it changes the run time environment too much. I've never attempted remote debugging with Visual Studio before, so what is the "best" way to get line by line remote debugging of server side web app code. I'd like to be able to set a breakpoint, attach, and start stepping line by line to verify code flow and, you know, debug and stuff :).
I'm sure most of the answers will pertain to ASP.NET code, and I'm interested in that, but my current code base is actually Classic ASP and ISAPI Extensions, so I care about that a little more.
Also, my test server is running in VMWare, I've noticed in the latest VMWare install it mentioning something about debugging support, but I'm unfamiliar with what that means...anyone using it, what does it do for you?
First, this is MUCH easier if both the server and your workstation are on the same domain (the server needs access to connect to your machine). In your C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86 (or x64, or ia64) directory are the files you need to copy to your server. There are different versions between Visual Studio versions, so make sure they match on the client and server side. On the server, fire up msvsmon. It will say something like "Msvsmon started a new server named xxx#yyyy". This is the name you'll use in Visual Studio to connect to this server. You can go into Tools > Options to set the server name and to set the authentication mode (hopefully Windows Authentication) - BTW No Authentication doesn't work for managed code.
On the client side, open up Visual Studio and load the solution you're going to debug. Then go to Debug > Attach to Process. In the "Qualifier" field enter the name of the server as you saw it appear earlier. Click on the Select button and select the type of code you want to debug, then hit OK. Hopefully you'll see a list of the processes on the server that you can attach to (you should also see on the server that the debugging monitor just said you connected). Find the process to attach to (start up the app if necessary). If it's an ASP.NET website, you'd select w3wp.exe, then hit Attach. Set your breakpoints and hopefully you're now remotely debugging the code.
AFAIK - the VMWare option lets you start up code inside of a VM but debug it from your workstation.
Visual Studio comes with a remote debugger that you can run as an exe on your server. It works best if you can run it as the same domain user as your copy of visual studio. You can then do an attach to process from the debugger on your machine to the IIS process on the server and debug as if it was running on your machine. You get more options for .Net debugging, but there's support for older platforms too.