Page 2 of 2

Re: How to Install

PostPosted: Thu Aug 19, 2010 9:08 pm
by LemoN
Feel free mate. :)

Re: How to Install

PostPosted: Sat Aug 21, 2010 5:27 pm
by Zarat
T-Dawg wrote:This is really odd, and seems difficult to solve... I'll try to hunt down a local computer which shows the same symptoms so I can track the issue down. I can hardly expect more of your time. :<


Ehm this is easy to solve. You are referencing Microsoft.Xna.Framework.Content.Pipeline.dll (as above screenshot says), but this is a dll from the developer sdk and not included in the XNA installer.

Any hard reference to a missing assembly can cause an exception sooner or later (whenever the JIT sees code using the assembly, which can vary depending on framework version and how agressive the JIT compiles ahead of time). You'll have to remove the reference from the project and either delete the code using it, or move it to a secondary assembly and dynamically load it when you decide its safe to do so. If you are relying on the content-pipeline to modify data you should use your own xml or binary format because as far as I can tell XNA resources are meant to be read-only.

Re: How to Install

PostPosted: Sun Aug 22, 2010 12:00 pm
by T-Dawg
Zarat wrote:Ehm this is easy to solve. You are referencing Microsoft.Xna.Framework.Content.Pipeline.dll (as above screenshot says), but this is a dll from the developer sdk and not included in the XNA installer.


Unfortunately, that problem was when he tried to start an old garbage file from back when I used the OneClick-approach. I accidentaly added the application-file to the .rar he downloaded. If that was the problem, then no-one without XNA Game Studio installed would have been able to run the program, unless I'm mistaken.

Re: How to Install

PostPosted: Mon Aug 23, 2010 6:33 am
by Zarat
I see. Good luck on finding the problem then!

About everyone not being able to start ... that would be true if you actually used the code. DotNet usually delays loading types (and references) until it really needs them. So if the code is executed only under very specific conditions most people would never hit it.

I'd still suggest removing the reference. Unless its all dead code this reference is a ticking time bomb (and if it is dead it's safe to remove anyways). You don't need to execute the code using the missing reference to blow it up, it's enough to have the type containing the code appear in a method signature or something. The problem here is that it's not exactly specified how far ahead the JIT looks when loading stuff. Since this is an implementation detail it could even change with windows updates (and it did in the past, code from the company where I work suddenly stopped working if a certain hotfix was installed :lol:).