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.
Related
I am currently updating a VB.NET application with Visual Studio 2013 that possibly was originally created on VS2010 or VS2012.
This application uses a Network SQL Database
Everything goes fine up to the point of installing when just shows an error message. that says the Assembly 'Microsoft.VisualBasic.Shell.9.0' version 2.0.0.0
is required and then will not let me finish the installation.
The project has been exported using the Visual Basic tool [OneClick]
I have already checked the References list on the Project menu, and is not included there. Also not available to be added.
The project requires the Microsoft Framework 4.5, so it seems that the Shell v2.0.0.0 is pretty old...
Do you have any suggestions, this kept me scratching my head already quite a while...
I finally figured it out.
I am not too sure if this is the right solution or not but it worked for me. Hopefully this will help someone else.
It turn out to be a error with the framework I was compiling the project (v4.5),
I was trying to install it on a Windows 7 machine with a framework installed up to v4.0. I cant understand why this error message showed up instead of telling me the framework version required for the software was not installed.
But anyways, I changed the version on the compiler, build and export again. Another error pop up but it was because references to the DLL for the different framework version were not included in the project. After including them and set the value for "Copy to Local" to true, the installation worked like a charm.
So I got my program up and working.
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.
After allowing Nuget to update ImageResizer 3.1.5 to version 3.2.1 my compiles are failing with multiple errors (all same type):
Error 5 Missing compiler required member 'System.Runtime.CompilerServices.ExtensionAttribute..ctor'
Apparently this is the result of an assembly version mismatch. Deleting all ImageResizer references in the project allows an error-free compile.
Reverting to ImageResizer 3.1.5 also allows a successful compilation.
My project is a simple MVC3 application targeting .NET4 - both ImageResizer 3.1.5 and 3.2.1 are targeting v2.0.50727
Any ideas on how this could be fixed?
Thanks in anticipation!
Update (Jun 20th 2012): The best solution is for the project to roll back extension method support. ImageResizer 3.2.2 will no longer offer extension methods, but some of the functionality will be duplicated in the ResizeSettings and Instructions classes to minimize breakage for those who have already coded against the new alpha APIs.
ImageResizer V4 will most likely require .NET 3.5, and will re-introduce the missing features.
Update: please see this question instead if you have any solutions to this catch-22.
I apologize for the issues.
I'm still trying to gather data and discover a long-term solution, but this is what I have so far:
Workaround A:
In Solution Explorer, expand the References folder in your project, select ImageResizer, and go to Properties. Change the Aliases field from 'global' to 'ir'.
Workaround B:
Set your project to use .NET 2.0, save, then revert it back to using .NET 3.5 or .NET 4.
Workaround C:
Manually remove your System.Core reference and add the correct one back. (The usual culprit is an upgraded project with a System.Core 3.0 reference in a 3.5 project). On ASP.NET, you can do this in web.config.
Workaround D:
Revert to 3.2.0, but only if you're using C#.
Why this is happening
VisualStudio/MSBuild find multiple definitions of System.Runtime.CompilerServices.ExtensionAttribute in the project during compilation, but instead of picking the public copy defined in System.Core, the compiler decides to use the internal, assembly-local copy defined in ImageResizer.dll. Then it complains because other assemblies can't reach it. Inane.
What should happen
Microsoft has used this technique several times in the past without issues, and it's widely documented. The compiler is supposed to pick the public instance for project-wide use, but instead it's picking the 'internal' copy. And this isn't affecting many developers; and only a few can reproduce it with a new project.
Public vs. Internal
V2.3.0 defined ExtensionAttribute as public instead of internal. This caused a compile-timer error in VB projects, but not in C# projects. I immediately released 2.3.1 with it marked internal, but I'm now seeing problems with C# projects instead. Catch-22 here.
It works for other people... and Microsoft! Why me?
http://www.danielmoth.com/Blog/Using-Extension-Methods-In-Fx-20-Projects.aspx
http://www.codethinked.com/using-extension-methods-in-net-20
http://kohari.org/2008/04/04/extension-methods-in-net-20/
Using extension methods in .NET 2.0?
The 'hack' was even featured in MSDN magazine.
How you can help
I need more data to completely figure this out. If you're experiencing the issue, please e-mail a .zip file of the project to support#imageresizing.net, and include your VisualStudio/.NET version numbers (Go to Visual Studio, Help, About, and click Copy Info, then paste it into the e-mail).
Hopefully I'll be able to find the exact circumstance(s) that trigger the problem.
Update - just found this article which implies the only solution is creating multiple versions of the assembly. But Microsoft didn't! What am I missing? Also, NuGet doesn't support 2.0 vs 3.5 versioning, so unless I can find a single-assembly solution I might have to drop 2.0 support.
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.
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.