Do the rational tools follow the _NT_SYMBOL_PATH to find .pdb files? It seems from my experience that they are not and that the .pdb files need to be collocated with the .dll's and .exe's I am trying to intrument.
I eventually found some references that indicate that the pdb and dll/exe need to be collocated.
Verify that the .pdb file for the .exe or .dll is in the same directory as the corresponding .exe or .dll. The .pdb file contains the Microsoft format symbol information. If you move your .exe or .dll to a working directory, you must also move the corresponding .pdb file.
Verify that the pdb files are present in the same folder as the application modules so that the modules can be instrumented in precise mode. Precise mode instrumentation is a level of error-checking instrumentation that provides full runtime error detection and precisely pinpoints problems in any component in your program. If the application does not have the correct debug info, PurifyPlus will instrument in minimal mode and data will not be collected for that particular module.
Related
So I have an ASP.NET VB website that references several other projects (their DLLS are just put in the site's bin folder). I need to update a small piece of code in one of the projects, which I have done and it builds fine. However, when I copy over the new DLL to the website's bin folder it fails to build, and all the Imports statements say "BC40056: Namespace or type specified in the Imports xxx doesn't contain any public member or cannot be found", which results in a ton of errors like "is not defined" . There is no reference to the updated DLL in the website project's properties, but if I put the old version back it's all fine.
The project was copied from a server and the vbproj file contained references to other DLLs, but the HintPaths were a mixture of mapped drives and ..\..\..\. I've updated these so that they're all the full server location path, but this has made no difference. I tried adding the project to the same solution as the website and added a reference to the project instead, but this also made no difference.
I've done plenty of Googling but have yet to find a solution. Any help would be very welcome!
A few things
You don't want to just "place" the .dll's in the bin folder. One big reason is that when you do a "clean" project, the bin folder is deleted. So, anytime you do a clean project, what is in the bin folder is cleaned out. And a developer will often do a clean project if some kind of problem is occuring.
I would place those files in some folder in the project. (create a folder, or if its only one or two .dll's, then place them in the root of the project). At compile time, the .dll's will be copied to the bin folder. And if you using web deployment, then you can choose to have the .dll's all combined into one .dll. So, once again, you can see it makes little sense to place the .dll's in the bin folder, since during a build, they will not be required, and as noted, the resulting bin folder can and will as a "regular" development process be re-created (emptied out). I seen a good number of projects in which the developer did place the .dll in the bin folder (because they did not know where else to place the .dll's, and that was seemly the only place that the application worked. But, during a web build + deployment to the production server, those .dll's can be left behind - they not be copied to the final "deployment" build. (I'm basic saying don't do this!!).
You can also consider just creating folder called "packages" in the root. This is where all the nuget packages are placed. So, some folder for those .dll's is the idea here.
The other big issue? Well, just dropping some .dll's in some place does NOT give you the developer all the methods and properties of those .dll's when writing code (we are assuming these are managed code - not win x32 .dll's).
So, without adding a reference to that assembly, then I can't see how the project will even compile correctly, and how syntax checking, and general use of the assembly will ever work during the development process (so VERY perplexed that you don't have references to those .dll's - that as a general rule can't work).
Now, to use the assemblies? Yes, you want to add the .dll as a reference to the project.
So, in references, add the .dll as a reference.
And then in the property sheet for the refence? Make sure you have the "copy local" set = true.
eg this:
So, above is GhostScript.net reference. (a open source library to manipulate pdf's).
Note the long path name for the .dll location. But, MOST important is the copy local setting = true. This means during a compile and build (which as noted can clean out the bin folder), then the .dll will be output to the final build in the bin folder.
So, I can't see how you can compile anything without an actual reference to the .dll. That is quite much assumed and a given - else I see no way how your project can compile under any circumstances.
So, referance the .dll, and that should allow use of the class(s) and objects, and enable your code to compile. And make sure the copy local = true, as that is the process that will copy + place the .dll in the final output (bin) folder when you compile.
So it turns out that the project for the DLL I was trying to reference had the Target CPU set to x64. Changing this this to 'AnyCPU' then allowed me to reference it.
This post gave me the answer: Could not load file or assembly ... An attempt was made to load a program with an incorrect format (System.BadImageFormatException)
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.
I am working with a precompiled ASP.net website. I have most of the *.aspx.vb files, but I am missing some of the library files, and only have the DLLs. Can I still selectively compile aspx.vb files? When I just hit build, It errors with 'This application is already precompiled'
If you have DLLs, then most likely those are external assemblies which are not part of the project, to which the source files belong. So if you have a project file, try compiling it and see if it reports missing source (.vb) files. Most likely compiler will give you hints regarding particular problems.
If you don't have a project file, the situation becomes more complicated. You might need to use some decompiler tool (9rays.net decompiler is a good one) to restore the source files from compiled DLL (note - main project DLL, not those library DLLs) and analyze what's missing and what was included.
When I try to run test with FlexUnit4 and IntelliJ, I get this error:
SecurityError: Error #2148: SWF file file:///C|/Users/LIC/Projects/ProgramJef/out/production/Flex%2DClient%2DTests/%5Fflexunit.swf cannot access local resource file:///C|/Users/LIC/Projects/ProgramJef/out/production/Flex%2DClient%2DTests/textLayout_1.1.0.604.swf. Only local-with-filesystem and trusted local SWF files may access local resources.
at flash.net::URLStream/load()
at flash.net::URLLoader/load()
at mx.core::CrossDomainRSLItem/load()[E:\dev\4.x\frameworks\projects\framework\src\mx\core\CrossDomainRSLItem.as:240]
at mx.core::RSLListLoader/loadNext()[E:\dev\4.x\frameworks\projects\framework\src\mx\core\RSLListLoader.as:184]
at mx.core::RSLListLoader/load()[E:\dev\4.x\frameworks\projects\framework\src\mx\core\RSLListLoader.as:156]
at mx.preloaders::Preloader/initialize()[E:\dev\4.x\frameworks\projects\framework\src\mx\preloaders\Preloader.as:279]
at mx.managers::SystemManager/http://www.adobe.com/2006/flex/mx/internal::initialize()[E:\dev\4.x\frameworks\projects\framework\src\mx\managers\SystemManager.as:1925]
at mx.managers::SystemManager/initHandler()[E:\dev\4.x\frameworks\projects\framework\src\mx\managers\SystemManager.as:2419]
I really wouldn't know what the problem is here, and I can't find anything on it online. Even on IntelliJ and FlexUnit4 there's not much to find...
You must allow the resulting SWF access to your file system. Set the Flashplayer trust settings in a file. On Linux this file must be in
~/.macromedia/Flash_Player/#Security/FlashPlayerTrust/
(for Windows there is a similar path somewhere) and create a file that lists the output path of your project, e.g.
/dev/myproject/target
/dev/anotherproject/target
In case 'target' is our output folder.
Did you set up your test sources folder right? In Project Settings under Modules, add Flex and click Flex and add Text Source Folders using the tree structure on the right hand side.
(IntelliJ 9.0.2)
Basically, Qt provide the cross-plateform.
I have made a application which is used Qt creator on Linux.
But, I can't be running that on Windows because it can't find .dll files such as mingw10.dll and qtcore4.dll, etc.
So, I have copied the .dll files which can be found in qt/bin directory.
And, I create a directory in order to save that like /lib becuase of distribution of application.
But, I can't set up path in .pro file.
How to set up the path for .dll?
Thank you.
You can too compile QT statically in order to not have to link dlls to your exe.
You say you've successfully compiled the app, so the only problem is that it can't find the DLLs.
There are a few solutions, and they have nothing to do with the .pro file. Your two best bets are:
Make sure the DLLs are in the same directory as the .exe file
Make sure the DLLs are in a directory contained in the PATH environment variable