i'm trying to change a DLL of a Net 4.0 Application with Reflexil. The directory looks like this:
Main.exe
SomeOther.exe
Lib1.dll
Lib2.dll
Lib3.dll
...
Now I'm trying to change some IL code in any of these files with Reflector 7.5.3.8 Trail and Reflexil 1.5. For example, I remove all the code from the Main() method in Main.exe (THE main method, I'm sure about this) leaving nothing but a ret. After saving the changes, I still don't see any effect, the program starts as usual.
I guess the problem is, that there is still a cached version of that file somewhere. How do I solve that problem?
What do I have to do to change IL code of the DLLs?
After many hours of work, I finally found the problem.
At installation, the program generated NativeImages - nothing unusual so far. The Problem was, that
ngen uninstall Lib1.dll
or
ngen uninstall Main.exe
did not uninstall the Native Image. Why? I had no idea... I tried
ngen display Lib1.dll
and it said, there's no such assembly. By coincidence, I tried to list the whole Native Image Cache with a find:
ngen display | find "Lib1"
which showed me, that it is still in there (why that?!). This time I tried to uninstall it not by uninstall Lib1.dll, but by executing
ngen uninstall Lib1 (without dll)
which worked like a charm and told me the problem. It didn't uninstall it, because other assemblies in the Native Image Cache still depended on it. I had to uninstall all the dependent assemblies first, after that it was deleted automatically.
I hope this is of some help. I think it's really confusing to distinguish between the file and the assembly in general...
Related
During installation I get "The feature you are trying to use is on a network resource that is unavailable" and prompt to specify some path to vc_runtimeMinimum_x64.msi. After providing some path to required file I get error states that this file doesn't match required version Minimum Runtime 14.14.26405.
I finally found the solution reading this question: Install vcredist_x64 with VS2017 installer project
I realized that specific VC_Redist.x64.exe files could be downloaded by links like https://aka.ms/vs/15/release/26405.00/VC_Redist.x64.exe, where 26405.00 is exactly the version I was required to fix. Note, that you need version from error text after clicking OK, not from window title.
And the last point is that this exe must be executed from cmd with argument /repair to help me with this issue. Regular execution by double click made no effect.
I found the solution elsewhere. It said to
Fix problems that block programs from being installed or removed
https://support.microsoft.com/en-us/help/17588/windows-fix-problems-that-block-programs-being-installed-or-removed
download troubleshooter button on the link.
Run it - choose option - have problem with installing - it lists programs - choose the missing / problematic visual c++ runtimes in the list
it will run and get fixed.
Repeat for each visual c++ you having problems with. I ran the program multiple times.
I have to thank this comment section for helping me with this problem, since I have not been able to work more efficently with my school, since I din't know what and if a single file somewhere deep down in the computer had to be deleted for this program to work.
I've been trying to get the sdl2 ttf extension library to work. I am able to compile code without issue, but when running the exe, via command line, I get the following message popup. "The application was unable to start correctly (0xc0000007b). Click OK to close the application" searching for others with similar issues, it seems like the issue they had was that they had put the wrong version of the dll in their system32 directory, but I have tried putting both the 32 and 64 bit versions in and neither worked (the 64 bit one is what should work). Any ideas on what else could be causing this?
Turns out the problem was just that I didn't also copy over the libfreetype-6.dll
My goal was to update a reference from my old DLL to a newer version that was updated to VS2012.
D:\DEV\<old_path>\TEST\bin\Company.dll
D:\DEV\<new_path_2012>\TEST\bin\Company.dll
In the .vbproj file...
<Reference Include="Company, Version=0.0.0.0, Culture=neutral">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\<new_path_2012>\TEST\bin\Company.dll</HintPath>
</Reference>
In the Solution Explorer, Under References, I right-click on the Company reference and click Properties. The Path is listed as...
D:\DEV\<old_path>\TEST\bin\Company.dll
There are no errors or warnings. Everything is appearing to build properly however I lack confidence because of this discrepancy. How can I fix this?
I have tried restarting VS2012 and have tried deleting the TFS Cache. Downloading a fresh copy of this project from TFS on another PC seems to resolve the problem however I would like to better understand how to resolve this without such drastic measures.
I just had this issue crop up, and while this is an old thread it was the first Google result when I did my search, so I thought to offer what had happen for me.
TL;DR: Triple check the hint path - it could be wrong, and VS is using the DLL in the GAC.
My issue came up because I was using a little script to help me update over 250 projects worth of references, and had a small handful that didn't follow normal folder layout. So my hint path was 'correct' at first glance, but because it really wasn't, VS 2013 went to the version of the DLL in the GAC.
Once I clued into what was wrong and fixed the relative path for that project file, hint path and what was displayed in References matched up as it was supposed to.
I finally have my C++ Builder 2010 installation the way I want it, with all my components upgraded and installed. (touch wood)
I have been working with C++builder since version 1 and I know from countless previous traumatic experiences that this state of affairs could change in an instant. I would like to backup the installation and component set.
Is there a way to do this? A tool perhaps? A menu command that I have maybe missed all these years? I don't want to have to reinstall all the components from the bpl source again.
I make nightly backup images of my entire drive, I would like to do this for c++builder only if possible.
If it's a matter of simply copying files, which files would I need to copy? Are there entries in the registry that would need to be restored?
Thanks in advance for any thoughts and suggestions
The HKCU\Software\CodeGear\BDS\7.0\ registry section contains the "known packages" subtree that contains which components you have installed. reg export/import should save you some trouble.
You'll also want to backup/restore the actual files referenced there as well.
It has been a while since I used C++ Builder, but I will make two suggestions...
1) run regedit and looks for "builder". You will probably find a hive like hk_local_machine/software/codegear or such. Export that and you can import it later
2) have a look at GExperts - is they don't have the exact solution, they still have some pretty useful (and free) tools
The title of the question sums it up pretty well. I've downloaded the source for firefox 3.6 and built it (no errors), but when I try to run it, I get a warning that says:
(firefox-bin:2857): GLib-WARNING **: g_set_prgname() called multiple times
I'm not sure what to try now. Any suggestions? Or even a better place to ask this question?
*EDIT - It's not that I only get a warning, that wouldn't bother me. The problem is that the warning is the only thing that ever happens (no firefox windows show up or anything). When I run it from the terminal, that warning shows up twice and then nothing else happens (it just hangs and I have to Ctrl-C it).
Bug in Glib introduced while trying to fix https://bugzilla.gnome.org/show_bug.cgi?id=563627 and, as discussed in that bug, later backed out because of the issue you're seeing. The warning will go away once you get a newer version of Glib.
Quick comments:
It's a warning, not an error. This is not a problem but looks like the library wanted to be used differently. So why worry?
Why did you build it from source? If you want newer packages, I usuaully start with Debian sources and turn those into local packages -- as this incorporates whatever the package maintainers deemed worthy and will be closer to the package you will get at the next Ubuntu upgrade.