How can i change the base address of my dll
-
Project Properties - Build - Advanced in this dialogbox you can change the dll base address, but that ain't working for me, i always get the error DISP_E_BADVARTYPE. How come? Am i entering an invalid number? Can someone help me out here? thx
-
Project Properties - Build - Advanced in this dialogbox you can change the dll base address, but that ain't working for me, i always get the error DISP_E_BADVARTYPE. How come? Am i entering an invalid number? Can someone help me out here? thx
The Base Address must be a multiple of 64K (65536 decimal), cannot be lower than 64K * 256 and cannot be higher than 64K * 32768.
Dave Kreskowiak Microsoft MVP - Visual Basic
-
The Base Address must be a multiple of 64K (65536 decimal), cannot be lower than 64K * 256 and cannot be higher than 64K * 32768.
Dave Kreskowiak Microsoft MVP - Visual Basic
-
The Base Address must be a multiple of 64K (65536 decimal), cannot be lower than 64K * 256 and cannot be higher than 64K * 32768.
Dave Kreskowiak Microsoft MVP - Visual Basic
Big thx, i would give each assembly a fixed address, but how do i know how much space i have to leave between the addresses given to 2 different dll's?
-
Big thx, i would give each assembly a fixed address, but how do i know how much space i have to leave between the addresses given to 2 different dll's?
You don't really. Not without some work in the debugger to figure out what your resulting code size is anyway. Why do you think you need to do this anyway? The only real benefit is to speed up loading assemblies, but only slightly. All you're doing is (trying to) save the loader from having to calculate a starting address for you. This can also introduce unexpected problems. If an assembly won't fit in a hole that exists at the address you specify, or if the address is already being used by another assembly, then you actually increase the time it takes to load the assembly as the loader has to calculate a new address. -- modified at 12:05 Saturday 19th August, 2006
Dave Kreskowiak Microsoft MVP - Visual Basic
-
You don't really. Not without some work in the debugger to figure out what your resulting code size is anyway. Why do you think you need to do this anyway? The only real benefit is to speed up loading assemblies, but only slightly. All you're doing is (trying to) save the loader from having to calculate a starting address for you. This can also introduce unexpected problems. If an assembly won't fit in a hole that exists at the address you specify, or if the address is already being used by another assembly, then you actually increase the time it takes to load the assembly as the loader has to calculate a new address. -- modified at 12:05 Saturday 19th August, 2006
Dave Kreskowiak Microsoft MVP - Visual Basic
yep that is why i'm using it, to speed up the time of loading. But i'm just testing it out, now i saw it makes almost no difference. I also read by using NGEN, u can precompile your assemblies to use, does that help the speed of loading the application? I'm using an installer for install my project on client pc. So then i have to add a function to execute NGEN in a custom action in my installer?
-
yep that is why i'm using it, to speed up the time of loading. But i'm just testing it out, now i saw it makes almost no difference. I also read by using NGEN, u can precompile your assemblies to use, does that help the speed of loading the application? I'm using an installer for install my project on client pc. So then i have to add a function to execute NGEN in a custom action in my installer?
Timothy_1982 wrote:
to speed up the time of loading. But i'm just testing it out, now i saw it makes almost no difference.
Yeah, it doesn't take that long to calculate a new load address...unless you've got LOTS of .DLL's being loaded.
Timothy_1982 wrote:
by using NGEN, u can precompile your assemblies to use, does that help the speed of loading the application?
Yes it does. Probably not as much as you're hoping though. Alot of the overhead you see launching a .NET application is the startup of the Framework itself. There's just about nothing you can do about that.
Timothy_1982 wrote:
I'm using an installer for install my project on client pc. So then i have to add a function to execute NGEN in a custom action in my installer?
That's typically how it's done. Since NGEN produces binaries that are VERY processor specific, you can't just NGEN yourself a precompiled app and distribute that to everyone. Best practice is to include the NGEN step in the customer install and NGEN the application assemblies as the last step in your installation, using a custom action.
Dave Kreskowiak Microsoft MVP - Visual Basic
-
Timothy_1982 wrote:
to speed up the time of loading. But i'm just testing it out, now i saw it makes almost no difference.
Yeah, it doesn't take that long to calculate a new load address...unless you've got LOTS of .DLL's being loaded.
Timothy_1982 wrote:
by using NGEN, u can precompile your assemblies to use, does that help the speed of loading the application?
Yes it does. Probably not as much as you're hoping though. Alot of the overhead you see launching a .NET application is the startup of the Framework itself. There's just about nothing you can do about that.
Timothy_1982 wrote:
I'm using an installer for install my project on client pc. So then i have to add a function to execute NGEN in a custom action in my installer?
That's typically how it's done. Since NGEN produces binaries that are VERY processor specific, you can't just NGEN yourself a precompiled app and distribute that to everyone. Best practice is to include the NGEN step in the customer install and NGEN the application assemblies as the last step in your installation, using a custom action.
Dave Kreskowiak Microsoft MVP - Visual Basic
thx for all the answers, clear and usefull. ;)