I'm trying to use VS's attach to process tool to debug add-ins I'm developing for Sql Server Reporting Services.
I am able to correctly debug it with attach to process when I copy dll's and pdb's in my project debug/bin dir to the ReportServer/bin dir. But, if I use my msbuild script and copy those dlls and pdbs to the ReportServer/bin dir I get the wrong version.
1) How do I check the current version of a dll/tell if a dll is incompatible with another version?
2) And how do I tell what dll's/versions are loaded by the ReportServer process?
Thanks!
I don't know anything about Sql Server Reporting Services, but
1) you can inspect the version of a DLL with ildasm.exe
2) when you use VS 'attach to process', in the 'Modules' window it shows the version numbers of all the loaded assemblies
Related
I have a C++ DLL project in Visual Studio I've downloaded, which is a plugin module for another existing program (a media Player). The DLL created by this project is saved into the addon folder, is loaded by the media player and works great with no issues. However, I would like to be able to step through the code in the library while the player is running to understand how the code works.
The problem is that when I setup the project to launch the media player and step through the DLL project code, it starts fine and I can set breakpoints. But at certain times, the Visual Studio debugger tries to access other loaded DLLs inside the media player, which I don't have source code for, and it crashes the whole thing with an "access violation writing location blah blah blah" error. I have no interest in trying to access any other libraries the program is loading other than the one I have the source code for, so is there any way to prevent the Visual Studio Debugger from trying to hook into these other libraries? I know the error is not due to anything in the DLL project itself because it runs absolutely fine if I just tell it to "Start Without Debugging."
I have the source code for, so is there any way to prevent the Visual
Studio Debugger from trying to hook into these other libraries?
Please try these steps:
Suggestion
1) check Enable Just My Code under Tools-->Options-->Debugging-->General
2) enter Tools-->Options-->Debugging-->Symbols-->choose All modules, unless excluded and then click Specify excluded modules
then input the name of the dlls you want to exclude. Their symbols will not be loaded when you debug your application.
3) do not forget to uncheck option Warn if no user code on launch(managed only) under Tools-->Options-->Debugging-->General
How do I debug an assembly that's being used by a Report Services report running through SQL Server 2008 R2 Reporting Services?
I'm trying to debug using VS2012
It looks like the reports were created in VS2008 (VS9)
The assembly is targeted to .NET 3.5
I'm developing on my own dev machine and want to debug on this
One of the expressions in my report calls a method in a custom .dll
I've built the dll in debug mode, and deployed it, plus the .pdb file, to the default location (in my case, C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies)
I'm setting the breakpoint in VS2012 for the assembly code, which is contained in a distinct project
I run up the report in Firefox, then attach to the ReportingServicesService.exe process
I carry out some actions in the report that should trigger the code
The breakpoint isn't hit
Is there anything else I need to do to debug?
Got it. Here's what else I needed to do:
Open the report solution in VS2008
Open the custom assembly project in VS2012
Attach to process from VS2012, but attach to devenv.exe for the VS2008 instance
Click the report 'preview' tab in VS2008 - this runs the report, which is now hooked up to the VS2012 debugger :)
Here's some MSFT documentation on this (doesn't strictly relate to SQL Server 2008 R2):
http://msdn.microsoft.com/en-us/library/ms153693.aspx
I just completed my application development efforts on a D2D1 application using Visual Studio 2010 IDE in C++. I was exploring different ways of creating a package from this and used the built-in Visual Studio installer/setup. The setup project compiled smoothly and an install file was created. I was also able to successfully install the application according to my requirements. However, when I install it in the default location (which would be my preferred location - C:\Program Files(x86)), the application refuses to launch. Here is the debugging I was able to do so far:
Installed in C:\Program Files(x86): Application does not launch normally.
Installed in C:\Program Files(x86): Application launches when "Run as administrator"
Installed in a location other than %ProgramFiles% or %ProgramFiles(x86)%: Application launches normally without having to "Run as administrator".
I have tried cornering the error cases, but don't have anything conclusive or convincing so far, which is why I am seeking the experts help here. What I have done further:
Used Dependency Walker x86 version to figure out where/what the dll calls are through the profiler. It did not provide me with anything concrete - depends.exe believes my application has delay-load dependent modules GPSVC.dll and IESHIMS.dll and I am fairly certain that I don't need those. The profiler also indicates a CRT 0xC0000417 error - but it is difficult for me to say if it is related at all.
I do have a manifest defined for my visual styles as a pragma. Removing this did not help.
If this helps - my C++ project manifest file options in the Linker settings looks like this:
Generate Manifest - Yes
Allow Isolation -Yes
Enable UAC - Yes
UAC Execution level - As invoker
UAC Bypass UI Protection - No
I have converted all CRT functions to it's secure version (sprintf -> sprintf_s) as recommended by MSDN documentation. Is this even related here?
I have tried simply copying the .exe to %ProgramFiles(x86)%. It did not help - so it appears that my installer is not the one creating the problem.
I use _dupenv_s in several places within the code to retrieve %COMSPEC% , %TEMP% etc.
Any pointers to how I can proceed further with the debug is highly appreciated. I did read around about this and some experts suggest incorrect string handling or large or invalid directory names; but I don't see that as relevant in my case since the issue is unique to launching the application normally under %ProgramFiles(x86)% .
Other details:
* OS Windows 7 - 64 bit, Vista with latest SP - 32 bit
* Visual Studio Professional 2010, C++ Project with .Net client profile target
Visual Studio Installer; Target platform 32 bit
* Nature of application - Direct2D based
Pardon me if I did not use the correct technical terms. I am a novice in application deployment.
That is correct Viswanathan, you cannot write to Program Files/Program Files(x86) if you are not running from an elevated process.
If your application needs to write custom settings in a file when it is launched you should create a dedicated folder for it under CommonAppDataFolder
I have an error that I suspect might be caused by different versions of the CRT being loaded on two computers running Windows 7. How do I determine which version of MSVCR90.dll in the winsxs folder is being loaded?
My program is a DLL being loaded by another EXE. It is compiled using Visual Studio 2008 SP1.
As Al Kepp answered, you can use Dependency Walker, "Depends.exe". For DLLs that are dynamically loaded, the best way is to profile the application as it loads your library.
In Dependency Walker open the EXE, not your DLL. Then click "Profile-->Start Profiling". If the application requires arguments you can provide them in the window that opens, otherwise just click "Ok" to launch the program. Once the program is open, use it in the normal way so that it loads your DLL. Now that your DLL is loaded, you should be able to browse the tree in Dependency Walker to see which versions of the CRT are being used.
If you can't see the version, ensure that the full paths are shown in the tree by clicking the "C:\" button.
You can also see which version of the CRT the application or library is requesting by checking the manifest, which is generally, but not always included in the DLL or EXE. in Visual Studio, click "File->Open->File..." and select the EXE or DLL. Open the RT_MANIFEST resource and you should see some XML which lists the CRT as a dependency and the version.
Most applications using these language libraries in DLL files use simply the latest version of those DLL in Windows directory. If you for some reason need some specific version, the easiest what you can do is probably to put those correct files to the same directory as your exe.
You can use Dependency Walker application to see which DLL files are loaded into your process on startup. You can download it from Microsoft site for free.
I've written an event handler for sharepoint 2010 site using visual studio 2010 . I had attached a breakpoint to the code and followed the process which i had done in visual studio 2008.
It is to use the Attach to process option and select the w3wp option.
The event gets attached but the breakpoint is not firing.
I ve checked the site collection and checked the MAnage site settings to see if the event handler is enabled. It is enabled. I tried to disable and enable it again. Even now its not firing.
Also i tried to clean the build solution and re built it . The debugger is not firing.
Do post a reply
Thanks in advance
Baradhwaj.PC
Here are a few things to check:
Are you attached to the correct process?
Using appcmd.exe list wp on the server (IIS7+) can be a useful way to determine which process ID belongs to which App pool. If you attach to the wrong process ID, even if it is the right name, the breakpoint won't fire.
Are your PDB's installed with the .dll's?
When I use GAC-based deployments, I often use a PowerShell script to copy my PDB files into the GAC folder where the assembly lives, usually something like C:\WINDOWS\assembly\GAC_MSIL\MYLibrary\1.0.0.0_publickeytoken.
When using bin-based deployments, it is sufficient to ensure the pdb is also in the bin folder.
While debugging, check the "Modules" debug window.
Find your assembly to determine whether debug symbols were loaded. If they are not, read the reason why. Note that you may need to invoke your code at least once for the assembly to get loaded.
Sometimes, it might mention that the pdb version doesn't match the assembly. This might happen if you built and deployed without pushing out a new pdb, even if you made no changes to the code. If this occurs, just redeploy a freshly-built assembly and pdb.
Are the PDB files in the path in which you are debugging? Without the PDB files, I think Visual Studio will be unable to link your code to the breakpoints.