Re: [Mono-aspnet-list] .NET 4.5.1 + MVC 5
Curtis, before you update your post, bear in mind that deleting the Microsoft.Web.Infrastructure.dll prevents the app from working on .Net, so your registry access tip is still essential reading for aspiring cross-platformers. -- View this message in context: http://mono.1490590.n4.nabble.com/NET-4-5-1-MVC-5-tp4661331p4662043.html Sent from the Mono - ASP.NET mailing list archive at Nabble.com. ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-dev] Getting Started
Hi Dipam: I think you may discuss this issue in the MonoDevelop list: http://lists.ximian.com/mailman/listinfo/monodevelop-list Anyway, it seems the old ASP.NET web controls are not being used too much today. Many developers migrated to MVC and other frameworks. Anyway, good luck ;) Regards, On Sun, Feb 23, 2014 at 2:02 AM, Dipam Changede dipamch...@gmail.comwrote: Hello, i am 3rd year undergraduate student from BITS Pilani University in India majoring in Information Systems. I am well versed with technologies like C#, .NET, ASP.NET, and have been using them to create application from past 1.5yrs. I am new to MonoDevelop IDE (been using VS since start), but aim to contribute to it, and make it more powerful than it is now. *My current status :-* With guidance from Michael Hutchinson, i have build MD from source. Now i was browsing through the bugzilla page of monodevelop, to try fix some bugs. i came accross this bug :- https://bugzilla.xamarin.com/show_bug.cgi?id=1184 and I think it needs a immediate fix, as it doesn't give a good impression to first time users. so, please point me to appropriate module which needs fix Thanking you, Regards, Dipam Changede ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Atte, Juan Cristóbal Olivares *cxsoftware.com http://www.cxsoftware.com/* Skype: cxsoftware6001 Celular: +56-9 9871 7277 Central: +56-2 2348 7642 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ms .net source updated and license modified
Our current take at Xamarin is that we should avoid reading .NET source code when implementing similar functionality on mono. Some people have great visual memory, which would still mean us walking a fine line on their rights. This is specially true for new code. What this change is that is enables us is to verify their behavior when trying to understand compatibility issues, this is particularly good for binary formats as they are the hardest to reverse engineer for compatibility. It's meant to be a next step when exploratory testing/RE can't reveal the expected behavior. -- Rodrigo On Tue, Feb 25, 2014 at 4:59 PM, Martin Thwaites monofo...@my2cents.co.ukwrote: I'll caveat this with I'm not a legal expert... Doing a bit of research, according to Wikipedia, it's the most restrictive of the Microsoft Shared Source licences. It seems that it can be used for Reference use. I'd read this to mean that you cannot reproduce the identical code in mono, but, you could use to work out how it's doing what it does. Is this maybe something that has fallen out of the partnership between Xamarin and Microsoft? something that would allow the Xamarin to better develop their Android/iOS platform? I'd love to hear from Xamarin as I'm sure that their legal department either has an opinion, or helped instigate the change. Anyway, just my 2 cents. Martin On 25 February 2014 18:17, Stephen Shaw ss...@decriptor.com wrote: I'm curious. What does this actually mean for the mono project? Cheers, Stephen On Tue, Feb 25, 2014 at 11:16 AM, Chris Ball qha...@gmail.com wrote: Related, I believe: http://www.hanselman.com/blog/AnnouncingTheNewRoslynpoweredNETFrameworkReferenceSource.aspx Sent from my iPhone On 25.02.2014, at 18:50, \Andrés G. Aragoneses\ kno...@gmail.com wrote: On 25/02/14 18:11, theUser BL wrote: »Um die Arbeit mit dem Quellcode noch einfacher zu machen, hat Microsoft auch die Lizenzbestimmungen klarer gefasst. Denn bisher mussten beispielsweise die Entwickler von Open Source-Klonen aufpassen, dass sie nur Erkenntnisse aus dem Reverse Engineering verwenden und nicht aus dem Studium des originalen Quellcodes. Denn in vielen Fällen würde dann die Gefahr drohen, dass man sich verschiedener Rechteverletzungen schuldig macht. Die Microsoft Reference Source License wurde daher nun so angepasst, dass beispielsweise die Entwickler des Mono-Teams problemlos die .Net-Sourcen anschauen und das Framework dann unter Linux klonen können. « GoogleTranslate output is: To make the work with the source code even easier, Microsoft has also the license terms clarified. Because so far had For example, the developers of open source clones careful that they only use insights from the reverse engineering and not from the study of the original source code. Because in many cases would then the danger threatening that one different in rights violations guilty. The Microsoft Reference Source License was therefore now adapted so that for example, the developer of the mono-teams easily see the. Net sources and the framework then in Linux can clone. If this translation is (kind of) correct, it still is very confusing because that license (MS-RSL [1]) is not opensource. [1] http://en.wikipedia.org/wiki/Shared_source#Microsoft_Reference_Source_License_.28Ms-RSL.29 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Access violation
Hi all, In my application I do get an strange access violation error from an native-code DLL I'm calling. The same code does work with mono 3.0.x The Error does happen with precompiled mono 3.2.x and with 3.2.8 crosscompiled on Debian. The Error is risen within RpcRaiseException in rpcrt4.dll. What can be done to clear the Problem? Elmar ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-list] Comparison: Windows/WPF vs Mono/Glade/Gtk
Hello, Has anyone worked with Glade/Gtk on a Mono across platforms? Can you provide a comparison how it stacks up in comparison/contrast with native if you will .NET WPF? Assuming C# in all cases. Areas of interest: * Support for MVVM design patterns; I have some sense that possibly Glade/Gtk data binding is weak-to-none. That's significant, but perhaps not a non-starter. * Support for docking libraries such as Avalon; or just docking in general. Declarative Xml is one thing, and the ability to save and restore layout, content, etc. Any any other caveats, pitfalls, gotchas. Thank ye... Best regards, Michael ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MVC4 async controllers
Hi Daniel, Thanks the ping back. I know for sure that it's not the other parts of the code / view that is failing, since removing async Task... from the method declaration removes the error permanently. Adding async Task makes it fail 2/3 times approximately. I'll throw something up on github which shows the behavior and write in the thread again. --- Nicklas Overgaard iSharp Solutions ApS On Mon, Feb 24, 2014 at 1:33 AM, Daniel Lo Nigro li...@dan.cx wrote: The missing view errors errors are very annoying and misleading. They usually mean that something broke somewhere else but the exception wasn't caught. Are you logging exceptions via something like ELMAH? The actual exception may be in the logs if so. I'm surprised you could get async methods working in your controllers, last I heard there was nobody working on the async ASP.NET stack... On Wed, Feb 19, 2014 at 11:24 AM, Nicklas Overgaard nick...@isharp.dkwrote: Hi! I'm working on a Asp.net MVC4 project and I've started to use the async Task... returns on my controllers as it should improve performance quite a lot - and it all works wonderfully on Windows. However, from time to time, I prefer to work directly from my MAC via Xamarin Studio. Approximately 1 out of 3 requests to the XSP server works, the rest errors our randomly with missing view errors. I've noticed on the compatibility overview that the MVC4 async pipeline is not supposed to work at all: http://www.mono-project.com/Compatibility So i'm wondering: How come it helps to refresh the page? And is there any tricks to getting the async controllers working properly in XSP? Thanks! --- Nicklas Overgaard ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Embedded API. Numeric Boxing and GC
This code is wrong, it will fail when the object is moved since the
gchandle is not pinning the target.
Avoid pinning as much as possible since it does hurt performance a lot.
The solution is to remove the monoObject field and
use mono_gchandle_get_target against the GC handle.
On Tue, Feb 25, 2014 at 5:20 AM, jonat...@mugginsoft.com
jonat...@mugginsoft.com wrote:
I box my numeric primitives using a macro:
#define DB_BOX_INT64( x ) ( mono_value_box(mono_domain_get(),
mono_get_int64_class(), x) )
And use it like so:
1.
- (void)box
{
MonoObject *monoObject = DB_BOX_INT64(value);
}
I save the MonoObject * into a local variable. The collector will see the
object on the stack and collect it only when the enclosing function
completes.
2.
- (void)box:(long long)value
{
self.monoObject = DB_BOX_INT64(value);
self.gcHandle = mono_gchandle_new(self.monoObject, FALSE);
}
- (void)dealloc
{
mono_gchandle_free(self.gcHandle);
}
I save the MonoObject * into an instance variable. The collector will free
the MonoObject after the call to mono_gchandle_free().
Is the above correct?
Regards
Jonathan
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Embedded API. Numeric Boxing and GC
On 26 Feb 2014, at 16:15, Rodrigo Kumpera kump...@gmail.com wrote: This code is wrong, it will fail when the object is moved since the gchandle is not pinning the target. Avoid pinning as much as possible since it does hurt performance a lot. The solution is to remove the monoObject field and use mono_gchandle_get_target against the GC handle. Presumably objects are pinned by default when they appear in the stack. Yes? Jonathan ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Embedded API. Numeric Boxing and GC
On Wed, Feb 26, 2014 at 12:58 PM, jonat...@mugginsoft.com jonat...@mugginsoft.com wrote: On 26 Feb 2014, at 16:15, Rodrigo Kumpera kump...@gmail.com wrote: This code is wrong, it will fail when the object is moved since the gchandle is not pinning the target. Avoid pinning as much as possible since it does hurt performance a lot. The solution is to remove the monoObject field and use mono_gchandle_get_target against the GC handle. Presumably objects are pinned by default when they appear in the stack. Yes? Only in the C stack, but as soon as your (void)box:(long long)value method finishes executing, no stack references will be left. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
