I have the DLL and I have the exact sources used to create the DLL. I want our local symbol server to work when we get a dump file from customers. (Updating the DLL at the customer site can't be done before the next patch/release of our product)
That seems to be not possible. Have a look at this here: Why does Visual Studio require debugger symbol files to exactly match the binary files that they were built with?
Or this article: PDB Files: What Every Developer Must Know
Quote out of "PDB Files: What Every...":
The extremely important part is how the debugger knows this is the
exact matching PDB file for this binary. That's done through a GUID
that's embedded in both the PDB file and the binary. If the GUID does
not match, you certainly won't debug the module at the source code
level.
The .NET compiler, and for native the linker, puts this GUID into the
binary and PDB. Since the act of compiling creates this GUID, stop and
think about this for a moment. If you have yesterday's build and did
not save the PDB file will you ever be able to debug the binary again?
No! This is why it is so critical to save your PDB files for every
build. Because I know you're thinking it, I'll go ahead and answer the
question already forming in your mind: no, there's no way to change
the GUID.
Related
I am building an application with Lazarus where I use a sqlite database to store thousands of records. Right now I am linking to the sqlite library dynamically via the sqlite3.dll.
Is it possible to link to it statically? Where can I find the Lazarus compatible lib file to do that?
Note:
I only started using Lazarus and Free Pascal a month ago so something that might look very obvious to one, might not be for me. So bear with me a bit.
Cheers
Actual static linking is difficult since the TSQLite3Connection component is inherently designed to actively load the SQLite3 DLL. In other words, it's not linking against the library when you compile the program, the component is coded to dynamically load the DLL at run time.
If you are looking to have a totally self contained program, then you can accomplish this two different ways.
Create a new TSQLite3Connection component that links statically against sqlite3 instead of loading the DLL dynamically.
Include the sqlite3.dll as a resource in your program and have your program automatically deploy it before it runs.
Solution #1 is not trivial and not for the faint of heart. I've done it, and I intended to include a link to the component, but the result isn't stable. The problem is that you have to compile a static version of sqlite3, which isn't a real problem, but you have to do it with something like gcc under MinGW and that introduces issues. Compiling with gcc under MinGW means you have to then link in libgcc.a, and because FreePascal's internal linker doesn't know how to interpret stdcall symbols properly, you also have to link against MinGW's libkernel32.a, and libmsvcrt.a. The result just isn't stable. Crashes galore.
Solution #2 should be fairly easy, but the Lazarus maintainers make it a little hard. The part where you store the dll inside the executable as a resource is easy enough to do. And so is writing it out as a temp file. The problem is that you can't tell the TSQLite3Connection component where to find it after. So it looks in the executable's folder, or in system folders. Neither of which can necessarily be written to by the executable. The only place you can guarantee that your program will be able to write to is a temp folder. So what I did is created a new version of TSQLite3Connection component call TSQLite3DynConnection, meaning you can dynamically specify where the DLL is. I made a published property called ClientLibrary where you can specify the location of the dll (it doesn't have to end in .dll, so you can use system temp filename generation routines). You can get this component at: http://icculus.org/~kfitzner/misc/sqlite3dyndll.zip. It will compile against Lazarus 1.6.2 FP 3.0.0, or FP 1.0.6 / FP 2.6.0, which are the two versions I use.
I'll update this answer if I can get the statically linked version stable.
2 Dec 2016 update: I managed to get a static version stable.
This may be a stupid question and/or a futile effort -- you've been warned...
I have a ASP .NET application (with the VB parts compiled to a DLL). This application has been around a while and the person who wrote it apparently messed up the old source code repository system. He is no longer around and I'm not clear on whether the source code I was given was a re-write or an older version (or by some strange luck the actual version of the website running).
Being that part of this website is running as a DLL, what is the best way I can go about in determining if the version of the source code I have matches what is running? I'm unable to setup an IIS server to throw this on (licensing/server cost/time/etc).
Is there a better way than compiling the project and then finding some disassembler and doing a comparison?
Is there a better way than compiling the project and then finding some disassembler and doing a comparison?
That's what I've done in the past in your situation.
Open each compiled assembly using ILSpy, and use the option "File / Save Code" to generate source files.
Build the source code from your source code repository, and use ILSpy to generate source files.
Compare the results of 1 and 2.
Obviously this won't give you the whole picture - you'll also need to compare aspx files, config files, ..., but it's the only approach I know.
Is there a better way to modify the version information of a .NET assembly of the one I am currently using.
My current approach is the following.
I do disassemble the assembly with ildasm:
ildasm /nobar Riolo.WebUI.dll /out=Riolo.WebUI.il
This will generated also a Riolo.WebUI.res compiled resource file, that I then open and modify with the user interface of Visual Studio, then I do reassemble the assembly back with ilasm:
ilasm Riolo.WebUI.il /OUTPUT=Riolo.WebUI.dll /RESOURCE=Riolo.WebUI.res /DLL /PDB
There are various issues with this process, the main is obviously that I feel like shooting at a mosquito with a broadside of carronades, then that as I don't know how decompile .res files to .rc files with the command line, I cannot use a command line script, as I have to open Visual Studio to modify the .res file, which means it is very time consuming and somewhat error prone, and, last but not least, I do feel that roundtripping assemblies I may well end up loosing information, even if unwittingly, hence I am afraid I will early or later be bitten in some yet unforeseen scenario.
Until now my Visual Studio 2008 debugger gracefully stepped into Qt library code when I pressed F11. After upgrading Qt to the latest version and changing QTDIR, F11 does not step into library code anymore. Any clues how to make the debugger smart again?
Activate the modules list, Debug - Windows - Modules, to see what libraries are loaded and if debug symbols are loaded for those libraries. Note that you need to have the debugger active on your process to be able to do this.
In debug mode, the Qt libraries should be suffixed by d. QtCored4.dll for instance. If you see QtCore4.dll on the list, you have linked to the wrong libraries. If it does say QtCored4.dll but under Symbol Status there is something different than Symbols loaded., then that's the reason. You can manually load the symbols here by right clicking on the dll and selecting Load Symbols. It asks for the Pdb file after clicking that.
You can add more pdb file locations, if they weren't loaded but exist, from Tools - Options - Debugging(tree) - Symbols(tree). If you want the symbols to be automatically loaded.
Should it give some error, that the pdb file doesn't match the binary or something like that, you should re-build your Qt debug version, unless you have more pdb files to try. Use the Visual studio command prompt and go to the Qt directory, run configure and nmake. It takes a while, possibly some hours. There was some switch to only build debug version but i forgot where it goes. Note that the build might fail and after that it's a lot of fun www.google.com searches. The best bet might be to get the source only package, I forgot where to get that and it's not easily found. If you know where to get it, tell me please. I vaguely remember that there might be some other way to build the debug version, but this is the only one i know for sure.
#0xbaadf00d's recommendation to "open the Debug/Windows/Modules view" for verifying which modules have loaded successfully and which are not loaded is extremely useful.
Here is a summary of what I check when I need to step into Qt source code:
The DLLs must be for the Qt version in developer's Qt kit
The Qt .pdb files must be present in Qt kit's folders: bin, lib, plugins/platforms, plugins/qmltooling
Visual Studio Tools/Option/Debugging/Symbols needs paths to .pdb files:
If qt.conf file is used, must point to correct bin folder
If target is WinCE or WEC2013 and using HKLM\Loader\SystemPath, you must specify path to DLLs in SystemPath variable
Set the location for the source files in the project property pages:
After pre-compiled a ASP.NET web site, I got many files with the names like
App_Web_accountbalance.aspx.dfa151d5.dll
Do you know the rule for the random chars (in bold) above?
Can we fix the random chars?
The reason to fix it is that if we modify AccountBalance.aspx file later and re-compile the web site, can we just replace App_Web_accountbalance.aspx.dfa151d5.dll.
Thank you.
The characters are not random, but more in line with hashing. The purpose is to make the file name unique in the bin folder. Although not advisable, you can replace just certain files to update your website. If you modify AccountBalance.aspx and recompile, you need to replace App_Web_accountbalance.aspx.dfa151d5.dll, accountbalance.aspx.dfa151d5.compiled, and other assemblies and files that your aspx file depends.
I derived the answer from my experience. I was not looking for the file naming rule, but a way to deploy just the assembly of a changed page, same reason as the original post.
The setup:
A web application, deployed non-updateable (updatable=”false” in PrecompileApp.config), pre-compiled assemblies with no fixed names
What I did:
Make the change to the page (say, a.aspx) in development (Visual Studio 2010)
Publish the site with fixed naming to local drive (Build > Publish Web Site, check the box: Use fixed naming and single page assemblies)
Go to the bin folder of the local publish site and look for a.aspx.xxx.compiled
Open the file with Notepad and note any dependency (say, b.aspx, c.master)
Copy all the affected assemblies and the .compiled files to the bin folder in production server. In this example, they are:
a.aspx.xxx.compiled
b.aspx.xxx.compiled
c.master.xxx.compiled
App_Web_a.aspx.xxx.dll
App_Web_b.aspx.xxx.dll
App_Web_c.master.xxx.dll
If you want to know my story, the change was due to a change in a factor in a calculation. The customer knew of the change much earlier, but did not let us know until it became urgent. A proper deployment would involve other parties and much coordination, and would be too late. Plus, I only had the source code of two versions back, and requesting the latest would take time. So, a hot fix on just that calculation change was required as a temporary measure.
1) you can generate single assembly per web application if you want. So when you make a change in web application, you only need to deploy just one dll.
for this, you can check option "Use fixed naming and single page assemblies"
2) Reference from MSDN Article: "The assembly names are generated automatically by the compiler and it is therefore not obvious which assemblies map to which source files. The compiler also creates new names each time it runs, so that the names of assemblies might not be the same after each compilation. In addition, if source files have changed, the compiler might batch up source files differently, meaning that the resulting assemblies do not necessarily represent the same source files. If you are maintaining a deployed Web site and want to update only the assemblies for recent changes, the output from batch compilation can make that job more complicated.
To help you in this situation, aspnet_compiler.exe supports an option specifically designed for packaging and release management: the -fixednames option. This option enables you to create compiler output that has two benefits. The first is that the assemblies produced by the compiler have the same names each time you compile. The second is that the assemblies are based on the same input files each time."
http://msdn.microsoft.com/en-us/library/aa479044.aspx