I have an year or so old application which uses Expression Encoder 3 to generate thumbnails. Few of the users are complaining that they are receiving the following exception:
Could not load file or assembly 'Microsoft.Expression.Encoder.Utilities.dll' or one of its dependencies. This application has failed to start because the application configuration is incorrect.
The application contains in itself the required EE3 assemblies in the setup, so as such installation of Expression Encoder is not required.
All these crashes started to occur after the application was upgraded to .net 4.
Any clues on what might be happening?
[EDIT] Was able to reproduce the issue on one of our local systems. We did a clean install of Windows XP. Installed .net 4 and then our app. It crashed with the same exception. We could fix the issue by installing .net 3.5!
I was quick to point fingers at .net 4 backward compatibility.
So the question remains: any clues on what might be happening?
According to this question this seems to be an issue with EE3 itself in that it requires EE to be installed (via the installer) to work properly.
Sadly this also seems to be the case for EE4, according to this thread, due to a codec licence issue.
Sorry :/
Have you looked at MediaFoundation? it might serve as an alternative, although ive never used it myself.
I had similar problems, where it wasn't working on a Windows7 64-bit server.
Here's some things I've learnt:
You must modify your project's build settings so it has a target platform of "x86".
You must ensure that the "Desktop Experience" feature is enabled on the target machine. See this blog.
Related
I'm trying to build a console app to test out redis/mono communication. I've been hitting a brick wall using Monodevelop 4.0 (Xamarin Studios)+Nuget Port to work with ServiceStack.Redis on mac os.
All the solutions I've found online only say, change the ".Net 4.0 Client Profile" into ".Net 4.0 full" on visual studios. I haven't found a related function on MonoDevelop, not even sure if such an option exists. So no help there.
The error I am getting is:
"The type or namespace name `RedisClient' could not be found. Are you missing a using directive or an assembly reference?"
The screencap below shows the missing references, even though it is clearly in the reference folder :(. It is very puzzling.
Has anyone had a similar problem? Any help would be appreciated.
I think this is generally an issue with lagging version numbers on Mono.
For example, here's an example that can reproduce the issue:
Your ServiceStack.Redis is compiled against ServiceStack.Interfaces -> 3.9.45.
But you've actually pulled the latest 3.9.48 versions of:
ServiceStack.Interfaces 3.9.48
ServiceStack.Common 3.9.48
ServiceStack.Text 3.9.48
Mono will have problems forwarding old ServiceStack references 3.9.45 to 3.9.48.
So, recompiling from source will resolve the issue.
Or, ensure all your references are using the same version number by opening up all ServiceStack.*.dll (as you've done) and ensure there are no lagging version number references.
Similarly, I had a problem with ServiceStack.Logging.NLog compiled against 3.9.44 packages which lead to various TypeLoadExceptions on Mono when the head version of ServiceStack.* is 3.9.48.
So after hair tearing fighting with the MonoDevelop IDE and nuget. I just resorted to building the Servicestack.redis from source in MonoDevelop, and copied over the output DLLs. This worked without a problem.
It seems either that monodevelop doesn't like the Dlls from nuget, or that the nuget port has some bugs with DLl references. Either way, I don't know the specifics, but there is a solution around it by building servicestack components from source in MonoDevelop.
I was having this same issue with Xamarin Studio 4.0.12 + NuGet Port running against Mono 2.10.9.
Yesterday I decided to try to get OrmLite working & when I went to add the package, I saw that there were ServiceStack updates available (to version 3.9.66.0 from 3.9.63.0). Installed the updates and added the OrmLite package and I started getting the same error...
"The type or namespace name 'OrmLiteConnectionFactory" could not be
found. Are you missing a using directive or an assembly reference?"
The weird part was Intellisense was working (I could fully qualify OrmLiteConnectionFactory in the IDE and it would find it fine) but it would not build. Just like you, I also saw in Assembly Browser that my ServiceStack DLLs were referencing previous versions of some of the other ServiceStack projects.
Upgrading to the latest Mono release (3.2.3 atm) solved the issue for me. Hallelujah! Not sure why I was using Mono 2.10.9 to begin with.
I have my dlls (.NET4) build with msbuild and obfuscated with SmartAssembly 5.5.
After that i set them with reference for simple console application in the MonoDevelop (latest) on Mac (10.8).
Built ok, but when i ran that simple app, i have a message:
Unknown heap type: SmartAssembly
I asked SA support but no luck yet (the saproj have item blabla(supports Mono) checked.
I dont see how to attach a screenshot, but, when i run my application i see in the console that message twice. It appears before program stops on the breakpoint on the first line of code.
So maybe someone knows what to change in SmartAssembly or in MonoDevelop to remove this problem ? Thanks
Many .NET obfuscators change the assemblies such that they are not technically correct assemblies (they fall outside the .NET assembly specs) but such that they still run on the Microsoft .NET runtime by exploiting bugs specific to Microsoft's implementation. I suspect they do this to make it harder for assembly reader tools/libraries to load the assemblies. Unfortunately, this also prevents Mono runtime from loading the assemblies. In general Mono has a policy of not "fixing" support for this kind of invalid obfuscated code, so you'll need to ask SmartAssembly support for help.
If you're certain you're compiling with SmartAssembly's "Strictly valid" option and it's not working, perhaps you could perhaps try their "Basic" option.
It does work on some machine's but wold not start on other computers.
from the code line's I see the problem is related to devex components.
this is the message I get:
We have reviewed your old posts and here is what we have found:
It seems, you were asked about Delphi interop, but Delphi creates x86 applications. Also, it seems, that your application fails on x64 systems. Since, VS creates ANY CPU applications, this most likely the cause of the problem. Try to build the application in VS for x86 platform, this should fix the problem.
I fixed the problem by using gacutil -i to add the dll to the assembly cache.
I have a VB.Net 1.1 application works just fine after compiling in Visual Studio. However, I want to use ILMerge to combine all the referenced assemblies into a single executable just to make it easier to move around. After I send it through ILMerge and try to run it I get the error
"Strong name validation failed for assembly.exe" .....
But none of my stuff is strong named! I saw this post here: Strong Name Validation Failed and tried running it through 'sn.exe -Vr merged.exe' but that gives me this error:
"merged.exe does not represent a strongly named assembly"
Has anyone else had this problem before? How do I fix it?
UPDATE:
I'm starting to feel like Strong name validation isn't the real problem here. I'm building against .NET v1.1 and running on a machine where that is the only .NET version installed (happens to be Windows 2003). The merged executable appears to die with that error on every Windows 2003 machine I try, but if I try to run it on a more modern OS (Vista) it at least starts, but that's not really a good test since the environment isn't fit for a real test.
I have verified that my app.config has the correct settings (specifying required and supported runtime version of v1.1.4322)
I use the /targetplatform:v1.1 option when running my assemblies through ILMerge.
ILMerge is definitely causing the problem (i.e. it works fine before I merge), I just don't know how to fix it.
I had to find and download a very old version of ILMerge (v1.1) in order for my merged binary to work; there must be a bug in the way the current ILMerge application builds .NET 1.1 assemblies. Thankfully we had one internally because I would probably have never found it online.
We have a project management application written in VB.net. When running this application from a 32-bit machine or from within the Visual Studio IDE on a 64-bit machine, it looks for the correct configuration file (i.e. MyApp.exe.config). However, when running this app from outside the IDE on a 64-bit machine, it looks for MyApp.config and fails to find it.
Obviously I can copy the correct config to the badly named config, but we're at a loss as to why this behavior is occurring in the first place.
This is a windows application written in the 2.0 framework. No web.config file is associated (as I have found some references to a similar issue with web.config files that didn't apply).
Any guidance or suggestions is greatly appreciated.
Edit: I also should note that this is the only application this is occurring on. If I create a new vb.net application using the same libraries we use for config management, it works fine. Also, of some possible relevance, the projects are being built targeting the x86 CPU.
What I'd do is on 64 bit at install time I'd do CreateHardLink("MyApp.exe.config", "MyApp.config", NULL)
CreateHardLink is P/Invokable.