I've installed mono 2.10 along with monodevelop and have used monodelveop to code some apps under ubuntu. Several of these apps needed to access to the JavaScriptSerializer, which is part of the System.Web.Script.Serialization namespace.
In order to be able to instantiate and use a JavaScriptSerializer, I had to add a reference to my app in monodevelop - but I see there appear to be two packages that I can chose from: one named "system.web.extensions" and the other named "mono".
If I use the first package (system.web.extensions) I get a runtime error when using the JavaSerializer. I tried using the "mono" reference instead and it works fine.
So far so good. But now, I want to run this same app under windows and I'm getting a "cannot load assembly" error for System.Web.Exceptions.
I'm confused at this point: Why are there two packages shipped with mono/monodevelop for some of these assemblies, and which one(s) should I be using in order to be cross-platform?
Thanks!
Michael
Why are there two packages shipped with mono/monodevelop for some of
these assemblies?
Mono assemblies are kinds of internal assemblies: they provide additional features, not included in the .NET Framework. The System assemblies rely sometimes on these (i.e. Mono.Web for ASP.NET Web services).
Which one(s) should I be using in order to be cross-platform?
Always use the System ones. The Mono assemblies are not available under .NET Framework (unless you ship them manually).
Mono 2.10 provides two versions of the System.Web.Extensions assembly: 1.0.61025.0 and 4.0.0.0. Be sure to use the 4.0 version.
If the problem persists, could you post your code? (for me, no problem using the JavaScriptSerializer)
Related
Can anyone help as to how to use the run time binaries found in the link below?
https://www.microsoft.com/net/download/windows
Basically, we are moving to .NET Core (we have been using .NET framework 4.0 for many years - so big shift as you can guess). I am kind of nervous to install .NET core on the production server (Windows Server 2012). Is it safe to install .NET Core on a server running .NET framework 4.0? If no, is there any way I can get the .NET Core runtime on to the server without installing them (kind of copying portal libraries) so that I can start with the beta testing of the app. Any help would be much appreciated. Thanks!
EDIT:
It is not duplicate, One of the main questions I had if I can use portable binaries on the server to run my app, without actually installing them (got the answer below, thanks again). Not sure someone down voted this without any reason. It makes the developers nervous to ask a question in StackOverflow. if they can mention the reason that would be great!
There are no issues when installing .NET Core and .NET Framework on the same machine. They are designed to allow them to be installed side-by-side.
However you do need to install the .NET Core runtime onto the server to allow the code to be run because the OS has native dependencies that need to be present. See this link for more information.
With .NET Core you can do framework dependent deployments (FDD) and self-contained deployments (SCD). FDD requires any shared assemblies to be present on the server i.e. System.* assemblies etc. but an SCD only requires the basic runtime/native dependencies. For an SCD your app deployment would include any .NET Core shared assemblies in it's deployment package.
You can read more about FDD and SCD here
Also there is more information about the native dependencies on different OS platforms here
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'm having a problem with assembly resolution on an end-user machine and I believe it's related to using Portable Class Libraries....
I have a .NET 4.0 application that was originally written in Visual Studio 2010. Recently we upgraded to Visual Studio 2012 and we've created a few projects that are Portable Class Libraries. I don't believe we need these features now, but we're also building a Windows 8 Store application that might benefit from these libraries.
When I compile my project, what exactly does the portable library feature do? I expect that it allows me to run it on different frameworks without modification or recompiling.
When I look at the library in reflector dotPeek it shows the Platform attribute as:
.NETPortable,Version=v4.0,Profile=Profile5
And the references seem 2.0-ish:
mscorlib, Version=2.0.5.0
System, Version=2.0.5.0
System.Runtime.Serialization, Version=2.0.5.0
When I run the application on this end-user's machine, I see an error in the log file:
Could not load file or assembly, 'System.Core, Version=2.0.5.0...'
Googling System.Core 2.0.5.0 seems to refer to SilverLight -- which appears to be one of the targeted frameworks.
This machine does not have Visual Studio installed, but has .NET 4.0 (4.0.3 update)
Is there something I should be doing differently to compile, something I should investigate in my dependencies or something I should be looking to install on the end-user machine? What does the 2.0.5.0 refer to?
For .NET 4, you need an update (KB2468871) for Portable Class Libraries to work. From the KB Article:
Feature 5
Changes to the support portable libraries. These changes include API
updates and binder modifications. This update enables the CLR to bind
successfully to portable libraries so that a single DLL can run on the
.NET Framework 4, on Silverlight, on Xbox, or on the Windows Phone.
This update adds public Silverlight APIs to the .NET Framework 4 in
the same location. The API signatures will remain consistent across
the platform. All modifications are 100 percent compatible and will
not break any existing code.
Also see the "Deploying A .NET Framework App" section of the MSDN Portable Class Library Documentation.
EDIT: Actually, if the machine has .NET 4.0.3 installed as you mention, that should be sufficient. Can you double-check to make sure that it is actually installed?
I have an application that consists of a client-side application and a WebApi website.
My client-side stuff is targetting .NET 4 so that I don't have to insist that users install .NET 4.5. My website, however, is entirely under my control, so I'm targetting .NET 4.5.
There is one shared assembly, which I use for data access. It uses Entity Framework 5.
When I build the client application, the DLL used is version 4.4.xxx, whereas when I build the web application, the DLL is 5.0.xxx.
Up until now, I've been able to run the client application with no problems, and I've also been able to run the web application, again without problems.
However, I've now re-created my web application project from scratch (*), and suddenly I can't run it. I get a YSOD saying "Could not load file or assembly 'EntityFramework, Version=4.4.0.0 ..." at the point where my data-access assembly is first invoked.
Now, it's perfectly clear what that error means - it can't find the v4.4 DLL as used by the data-access assembly - but I don't understand why that's a problem with my new project when it wasn't a problem with my old project. As far as I can see, the same DLLs are referenced in each project.
(*) I should explain why I'm re-creating my project. I originally created the project in VS 2012 RC, and then later upgraded to the release version. Although this supposedly upgraded my project, I've had a few problems with it, and have also noticed some differences v. a newly-created project. So, to be on the safe side - and hopefully circumvent those other problems - I'm re-creating it from scratch.
So, my question: why is this suddenly a problem, and what can I do to resolve it?
Is the code depending on the assemblies set to require the exact version? If so, you will need a publisher policy for the EntityFramework assembly or bindingRedirect for the referencing application (web project).
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.