Why is XNA a framework download and not a DLL?
Author
It is a pain that end users must download the xna framework. Which got me wondering how come it is not just a DLL like most gfx engines?
Author
Not sure what ngen is.. GAC is when the dlls are placed in a special place on the computer or something
???
???
NGEN attempts to pre-JIT sections of DLLs or EXEs from managed code, based specifically on whichever computer it's run on. Let's say I have a .Net DLL that is installed on a 64 bit computer - it's theoretically possible (I'm not sure if they actually do this yet) for it to optimize the DLL for the 64 bit computer at install time.
GAC is the Global Assembly Cache.
I'm not sure how much code in XNA is actually managed, but I looked in the assembly cache and XNA *is* in there.
GAC is the Global Assembly Cache.
I'm not sure how much code in XNA is actually managed, but I looked in the assembly cache and XNA *is* in there.
Throwing around DLLs with your application is rather prone to causing certain problems, and MS has recently been moving away from that direction.
Part of the idea of using .NET, is the ability to have it compiled on the client machine, and therefore know the system's capabilities when it is compiled. This allows taking advantage of 64bit instruction sets on processors that support it, for examples. Releasing a DLL would require that one DLL to work with every possible system, and would therefore be less efficient on most.
Another very important issue is security. This is now becoming a hot topic, and MS is (wisely) trying to prevent spreading old DLLs around that cannot be updated if a security issue arrises. When XNA uses a "framework" installer to install the files into a specific place, these files can later be found and patched if a security issue arrises. If each application were to spread around it's own DLLs, finding them to patch them at a later time would be painfull.
There are some pretty cool tools out there that can let you install the XNA framework pretty simply, and with little user intervention, and with the webinstallers you won't even need to bloat up your downloadable to do so.
Hope this helps.
Part of the idea of using .NET, is the ability to have it compiled on the client machine, and therefore know the system's capabilities when it is compiled. This allows taking advantage of 64bit instruction sets on processors that support it, for examples. Releasing a DLL would require that one DLL to work with every possible system, and would therefore be less efficient on most.
Another very important issue is security. This is now becoming a hot topic, and MS is (wisely) trying to prevent spreading old DLLs around that cannot be updated if a security issue arrises. When XNA uses a "framework" installer to install the files into a specific place, these files can later be found and patched if a security issue arrises. If each application were to spread around it's own DLLs, finding them to patch them at a later time would be painfull.
There are some pretty cool tools out there that can let you install the XNA framework pretty simply, and with little user intervention, and with the webinstallers you won't even need to bloat up your downloadable to do so.
Hope this helps.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement