[Mono-list] .NET OPC UA client with Mono
Hello to all,
I downloaded from Siemens Website an example of a .NET OPC UA client
written in C#. Here's the link:
http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfoobjId=42014088nodeid4=20229805load=contentswitchLang;42014088;2.x=34switchLang;42014088;2.y=4lang=ensiteid=cseusaktprim=4objaction=csviewextranet=standardviewreg=WW
I'm not a software developer, but I am an enthusiast and I study .NET
programming as a hobby. Anyway, I work with industrial automation and I was
trying to port this example to MONO in Linux. Developing OPC clients can be
challenging, and I did before with the OPC DA Classic with some examples
that I found on the internet.
I can compile the project from the link with Mono and run the client. When I
click to connect to the OPC UA server(I'm runnig the Ignition OPC UA Server
for Linux), it gives an Crypt32.dll error. I debbuged the code and I found
that the client and the server verify certificates for establishing a
connection.
The routine for the client to verify the certificate is:
/using System;
using System.Collections.Generic;
using System.Text;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;
using Opc.Ua;
.
.
.
.
.
public static ApplicationConfiguration CreateClientConfiguration()
{
// The application configuration can be loaded from any file.
// ApplicationConfiguration.Load() method loads configuration by
looking up a file path in the App.config.
// This approach allows applications to share configuration
files and to update them.
ApplicationConfiguration configuration = new
ApplicationConfiguration();
// Step 1 - Specify the server identity.
configuration.ApplicationName = UA Test Client;
configuration.ApplicationType = ApplicationType.Client;
configuration.ApplicationUri =
http://localhost/VendorId/ApplicationId/InstanceId;;
configuration.ProductUri =
http://VendorId/ProductId/VersionId;;
configuration.SecurityConfiguration = new
SecurityConfiguration();
// Step 2 - Specify the server's application instance
certificate.
// Application instance certificates must be placed in a windows
certficate store because that is
// the best way to protect the private key. Certificates in a
store are identified with 4 parameters:
// StoreLocation, StoreName, SubjectName and Thumbprint.
//
// In this example the following values are used:
//
// LocalMachine- use the machine wide certificate store.
// Personal- use the store for individual
certificates.
// ApplicationName - use the application name as a search key.
configuration.SecurityConfiguration.ApplicationCertificate = new
CertificateIdentifier();
//
configuration.SecurityConfiguration.ApplicationCertificate.StoreType =
CertificateStoreType.Directory;
//
configuration.SecurityConfiguration.ApplicationCertificate.StorePath =
LocalMachine\\My;
//
configuration.SecurityConfiguration.ApplicationCertificate.SubjectName =
configuration.ApplicationName;
// trust all applications installed on the same machine.
//
configuration.SecurityConfiguration.TrustedPeerCertificates.StoreType =
CertificateStoreType.Directory;
//
configuration.SecurityConfiguration.TrustedPeerCertificates.StorePath =
LocalMachine\\My;
// find the certificate in the store.
X509Certificate2 clientCertificate =
configuration.SecurityConfiguration.ApplicationCertificate.Find(true);
// create a new certificate if one not found.
if (clientCertificate == null)
{
//// this code would normally be called as part of the
installer - called here to illustrate.
//// create a new certificate an place it in the
LocalMachine/Personal store.
//clientCertificate = CertificateFactory.CreateCertificate(
//
configuration.SecurityConfiguration.ApplicationCertificate.StoreType,
//
configuration.SecurityConfiguration.ApplicationCertificate.StorePath,
//configuration.ApplicationUri,
//configuration.ApplicationName,
//null,
//null,
//1024,
//120);
}
// Step 3 - Specify the supported transport configurations.
// The SDK requires Binding objects which are sub-types of
Opc.Ua.Bindings.BaseBinding
// These two lines add support for SOAP/HTTP w/ WS-* and UA-TCP.
Support for other protocols
// such as .NET TCP can be added but they would not be
considered interoperable across different vendors.
[Mono-list] .NET Foundation's Advisory Council
Hey guys, There is still time to join the discussion about the advisory council for the .NET Foundation: http://blogs.msdn.com/b/dotnet/archive/2014/11/24/advisory-council-proposal-call-for-community-feedback-extended-to-december-5th.aspx ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
In terms of the mono download, are you referring to a git clone? or the source tarball? In terms of clone, I'd say it's valid to be there, they may not change often but it would be good to see the version history within that fork, rather than having to compare across mono and the fork. However, for the tarball, we could strip out the files that aren't required with some kind of clever script. On 21 November 2014 18:35, Miguel de Icaza mig...@xamarin.com wrote: Follow up. I am wondering if we should submodule the reference source, or just copy the files? The module wont be updated frequently, and it is making the Mono download a lot longer than it needs to be. Miguel On Wed, Nov 19, 2014 at 12:48 PM, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] .NET and Mono integration, the plans
Hello Miguel, Thanks for sharing your strategy of incorporating or making use of MS' open-source. Your disclosure opens my eye particularly your remarks on CAS in Mono, a fundamental security framework of .Net, and not following the Object disposable pattern faithfully. One thing that is not very clear is: will this effort produces more consistent run time behavior between CLR and Mono whenever possible and where the library are not dealing with platform specific stuff? For example System.Diagnostics.Debug.Assert is not consistent but it should be. I am using Mono as a cross-platform tool and I have run into many inconsistent behavior - some I have work around but others I have no work around or even solution. Has Microsoft provided Mono team a set of testing harness to test the run time? Thanks. MarL -- View this message in context: http://mono.1490590.n4.nabble.com/NET-and-Mono-integration-the-plans-tp4664703p4664752.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET and Mono integration, the plans
Follow up. I am wondering if we should submodule the reference source, or just copy the files? The module wont be updated frequently, and it is making the Mono download a lot longer than it needs to be. Miguel On Wed, Nov 19, 2014 at 12:48 PM, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET and Mono integration, the plans
Hello, We have some test suites for the core that Microsoft has shared with us under a Microsoft/Xamarin agreement, but they are for just a few pieces, not the entire thing that is being open sourced. On Fri, Nov 21, 2014 at 1:35 PM, Miguel de Icaza mig...@xamarin.com wrote: Follow up. I am wondering if we should submodule the reference source, or just copy the files? The module wont be updated frequently, and it is making the Mono download a lot longer than it needs to be. Miguel On Wed, Nov 19, 2014 at 12:48 PM, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET and Mono integration, the plans
In terms of the mono download, are you referring to a git clone? or the source tarball? In terms of clone, I'd say it's valid to be there, they may not change often but it would be good to see the version history within that fork, rather than having to compare across mono and the fork. However, for the tarball, we could strip out the files that aren't required with some kind of clever script. On 21 November 2014 18:35, Miguel de Icaza mig...@xamarin.com wrote: Follow up. I am wondering if we should submodule the reference source, or just copy the files? The module wont be updated frequently, and it is making the Mono download a lot longer than it needs to be. Miguel On Wed, Nov 19, 2014 at 12:48 PM, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ 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-dev] [Mono-list] .NET and Mono integration, the plans
HI Miguel, Thanks, exactly what I've been waiting for! I only really have 1 question. In the ways that we are going to port things, you mention pulling in the entire assembly. How exactly would you be thinking this would work? try building and fixing anything that it depends from other libraries in the other libraries? or are you going to fork the reference source, submodule it, reference all the files in the .sources files within mono, then fix (i.e. add #ifdefs etc.) to the fork? Essentially, are you thinking that there will be an assembly that can simply be copied without changes in the above circumstance? Thanks, Martin On 19 November 2014 17:48, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
Hey, I do not think we would be moving the code. We would do two things: - Make changes to the fork in mono/referencesoure - Reference the new files from mono/external/referencesource Miguel On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: HI Miguel, Thanks, exactly what I've been waiting for! I only really have 1 question. In the ways that we are going to port things, you mention pulling in the entire assembly. How exactly would you be thinking this would work? try building and fixing anything that it depends from other libraries in the other libraries? or are you going to fork the reference source, submodule it, reference all the files in the .sources files within mono, then fix (i.e. add #ifdefs etc.) to the fork? Essentially, are you thinking that there will be an assembly that can simply be copied without changes in the above circumstance? Thanks, Martin On 19 November 2014 17:48, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
Hi Miguel, That sounds good. In terms of System.Web then, would you prefer your internal team does it? or am I ok to start replacing some files when the sub-module is added? I was thinking of trying to hit the HttpApplication class first and work my way out from there. Thanks, Martin On 19 November 2014 19:41, Miguel de Icaza mig...@xamarin.com wrote: Hey, I do not think we would be moving the code. We would do two things: - Make changes to the fork in mono/referencesoure - Reference the new files from mono/external/referencesource Miguel On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: HI Miguel, Thanks, exactly what I've been waiting for! I only really have 1 question. In the ways that we are going to port things, you mention pulling in the entire assembly. How exactly would you be thinking this would work? try building and fixing anything that it depends from other libraries in the other libraries? or are you going to fork the reference source, submodule it, reference all the files in the .sources files within mono, then fix (i.e. add #ifdefs etc.) to the fork? Essentially, are you thinking that there will be an assembly that can simply be copied without changes in the above circumstance? Thanks, Martin On 19 November 2014 17:48, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
On 19/11/14 20:50, Martin Thwaites wrote: Hey Martin, Hi Miguel, That sounds good. In terms of System.Web then, would you prefer your internal team does it? or am I ok to start replacing some files when the sub-module is added? I was thinking of trying to hit the HttpApplication class first and work my way out from there. Please be especially careful with System.Web - there are plenty of mines buried there. Both in our and in Microsoft code. The latter codebase uses a lot of native Win32 methods which may not have portable (POSIX, preferably) counterparts. Our code, OTOH, has a lot of cruft from the 1.1 days. The biggest problem with our code, however, is its reliance on an early (wrong) assumption that ASP.NET pages are, in fact, valid HTML. The parser is such a convoluted piece of misery that touching it in a wrong way causes System.Web to fall apart. If you want to start contributing I'd start there since there are issues we cannot fix using the current parser (especially the conditional parsing part). I dare say that System.Web will be one of the most challenging parts to port. Good luck and if you need any reviews and/or help don't hesitate to contact me. marek Thanks, Martin On 19 November 2014 19:41, Miguel de Icaza mig...@xamarin.com mailto:mig...@xamarin.com wrote: Hey, I do not think we would be moving the code. We would do two things: * Make changes to the fork in mono/referencesoure * Reference the new files from mono/external/referencesource Miguel On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites monofo...@my2cents.co.uk mailto:monofo...@my2cents.co.uk wrote: HI Miguel, Thanks, exactly what I've been waiting for! I only really have 1 question. In the ways that we are going to port things, you mention pulling in the entire assembly. How exactly would you be thinking this would work? try building and fixing anything that it depends from other libraries in the other libraries? or are you going to fork the reference source, submodule it, reference all the files in the .sources files within mono, then fix (i.e. add #ifdefs etc.) to the fork? Essentially, are you thinking that there will be an assembly that can simply be copied without changes in the above circumstance? Thanks, Martin On 19 November 2014 17:48, Miguel de Icaza mig...@xamarin.com mailto:mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - mono-l...@lists.ximian.com mailto:mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-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
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
Hey, I took a quick look at System.Web over the weekend, and I am not sure that it is that bad. Most of the native stuff has to do with performance counters and some authentication stuff on Windows (which we can skip/ignore). But the core of System.Web should be relatively easy to move. On Wed, Nov 19, 2014 at 3:28 PM, Marek Habersack gren...@twistedcode.net wrote: On 19/11/14 20:50, Martin Thwaites wrote: Hey Martin, Hi Miguel, That sounds good. In terms of System.Web then, would you prefer your internal team does it? or am I ok to start replacing some files when the sub-module is added? I was thinking of trying to hit the HttpApplication class first and work my way out from there. Please be especially careful with System.Web - there are plenty of mines buried there. Both in our and in Microsoft code. The latter codebase uses a lot of native Win32 methods which may not have portable (POSIX, preferably) counterparts. Our code, OTOH, has a lot of cruft from the 1.1 days. The biggest problem with our code, however, is its reliance on an early (wrong) assumption that ASP.NET pages are, in fact, valid HTML. The parser is such a convoluted piece of misery that touching it in a wrong way causes System.Web to fall apart. If you want to start contributing I'd start there since there are issues we cannot fix using the current parser (especially the conditional parsing part). I dare say that System.Web will be one of the most challenging parts to port. Good luck and if you need any reviews and/or help don't hesitate to contact me. marek Thanks, Martin On 19 November 2014 19:41, Miguel de Icaza mig...@xamarin.com mailto: mig...@xamarin.com wrote: Hey, I do not think we would be moving the code. We would do two things: * Make changes to the fork in mono/referencesoure * Reference the new files from mono/external/referencesource Miguel On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites monofo...@my2cents.co.uk mailto:monofo...@my2cents.co.uk wrote: HI Miguel, Thanks, exactly what I've been waiting for! I only really have 1 question. In the ways that we are going to port things, you mention pulling in the entire assembly. How exactly would you be thinking this would work? try building and fixing anything that it depends from other libraries in the other libraries? or are you going to fork the reference source, submodule it, reference all the files in the .sources files within mono, then fix (i.e. add #ifdefs etc.) to the fork? Essentially, are you thinking that there will be an assembly that can simply be copied without changes in the above circumstance? Thanks, Martin On 19 November 2014 17:48, Miguel de Icaza mig...@xamarin.com mailto:mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet- integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration- into-mono Miguel ___ Mono-list maillist - mono-l...@lists.ximian.com mailto: mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-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
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
On 19/11/14 21:51, Miguel de Icaza wrote: Hey, Hey, I took a quick look at System.Web over the weekend, and I am not sure that it is that bad. Most of the native stuff has to do with performance counters and some authentication stuff on Windows (which we can skip/ignore). I think also the caching subsystems use kernel APIs. But the core of System.Web should be relatively easy to move. Right, but we need to remember about mod_mono compatibility and the fact that changing the core (the sole System.Web namespace) has cascading effects on all the other System.Web things - it's not an easy task to make it all work fine. It's definitely doable, but may require a lot of work to get right. It would be great if we could replace just the System.Web namespace for starters, but I doubt it's going to be that easy. marek On Wed, Nov 19, 2014 at 3:28 PM, Marek Habersack gren...@twistedcode.net mailto:gren...@twistedcode.net wrote: On 19/11/14 20:50, Martin Thwaites wrote: Hey Martin, Hi Miguel, That sounds good. In terms of System.Web then, would you prefer your internal team does it? or am I ok to start replacing some files when the sub-module is added? I was thinking of trying to hit the HttpApplication class first and work my way out from there. Please be especially careful with System.Web - there are plenty of mines buried there. Both in our and in Microsoft code. The latter codebase uses a lot of native Win32 methods which may not have portable (POSIX, preferably) counterparts. Our code, OTOH, has a lot of cruft from the 1.1 days. The biggest problem with our code, however, is its reliance on an early (wrong) assumption that ASP.NET http://ASP.NET pages are, in fact, valid HTML. The parser is such a convoluted piece of misery that touching it in a wrong way causes System.Web to fall apart. If you want to start contributing I'd start there since there are issues we cannot fix using the current parser (especially the conditional parsing part). I dare say that System.Web will be one of the most challenging parts to port. Good luck and if you need any reviews and/or help don't hesitate to contact me. marek Thanks, Martin On 19 November 2014 19:41, Miguel de Icaza mig...@xamarin.com mailto:mig...@xamarin.com mailto:mig...@xamarin.com mailto:mig...@xamarin.com wrote: Hey, I do not think we would be moving the code. We would do two things: * Make changes to the fork in mono/referencesoure * Reference the new files from mono/external/referencesource Miguel On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites monofo...@my2cents.co.uk mailto:monofo...@my2cents.co.uk mailto:monofo...@my2cents.co.__uk mailto:monofo...@my2cents.co.uk wrote: HI Miguel, Thanks, exactly what I've been waiting for! I only really have 1 question. In the ways that we are going to port things, you mention pulling in the entire assembly. How exactly would you be thinking this would work? try building and fixing anything that it depends from other libraries in the other libraries? or are you going to fork the reference source, submodule it, reference all the files in the .sources files within mono, then fix (i.e. add #ifdefs etc.) to the fork? Essentially, are you thinking that there will be an assembly that can simply be copied without changes in the above circumstance? Thanks, Martin On 19 November 2014 17:48, Miguel de Icaza mig...@xamarin.com mailto:mig...@xamarin.com mailto:mig...@xamarin.com mailto:mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/__docs/about-mono/dotnet-__integration/ http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/__net-framework-integration-__into-mono https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel _ Mono-list maillist - mono-l...@lists.ximian.com mailto:mono-l...@lists.ximian.com mailto:Mono-list@lists.__ximian.com mailto:mono-l...@lists.ximian.com http://lists.ximian.com/__mailman/listinfo/mono-list http://lists.ximian.com/mailman/listinfo/mono-list _ Mono-devel-list mailing list Mono-devel-list@lists.ximian.__com
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
Will do, I'm on Gardening leave for the next week, so I've got sometime to look at it. Do you have an ETA on when the fork will be created and the sub-module added? On 19 November 2014 20:50, Miguel de Icaza mig...@xamarin.com wrote: Hey, Xamarin's team is not likely going to do System.Web, so feel free to step in. I am not sure if we can bring System.Web as a whole yet, I think it is a clear case of something that will have to be done in steps and starting with HttpApplication is as good as an idea as antyhing else. On Wed, Nov 19, 2014 at 2:50 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, That sounds good. In terms of System.Web then, would you prefer your internal team does it? or am I ok to start replacing some files when the sub-module is added? I was thinking of trying to hit the HttpApplication class first and work my way out from there. Thanks, Martin On 19 November 2014 19:41, Miguel de Icaza mig...@xamarin.com wrote: Hey, I do not think we would be moving the code. We would do two things: - Make changes to the fork in mono/referencesoure - Reference the new files from mono/external/referencesource Miguel On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: HI Miguel, Thanks, exactly what I've been waiting for! I only really have 1 question. In the ways that we are going to port things, you mention pulling in the entire assembly. How exactly would you be thinking this would work? try building and fixing anything that it depends from other libraries in the other libraries? or are you going to fork the reference source, submodule it, reference all the files in the .sources files within mono, then fix (i.e. add #ifdefs etc.) to the fork? Essentially, are you thinking that there will be an assembly that can simply be copied without changes in the above circumstance? Thanks, Martin On 19 November 2014 17:48, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
Hi Miguel, Have you come up with a plan on how to implement the resource methodology that's used for strings? i.e. the SR.GetString(SR.Name) type stuff? Are we just going to implement some partial class that we can add extend for each assembly? Theres loads throughout HttpApplication. Thanks, Martin On 19 November 2014 21:02, Martin Thwaites monofo...@my2cents.co.uk wrote: Will do, I'm on Gardening leave for the next week, so I've got sometime to look at it. Do you have an ETA on when the fork will be created and the sub-module added? On 19 November 2014 20:50, Miguel de Icaza mig...@xamarin.com wrote: Hey, Xamarin's team is not likely going to do System.Web, so feel free to step in. I am not sure if we can bring System.Web as a whole yet, I think it is a clear case of something that will have to be done in steps and starting with HttpApplication is as good as an idea as antyhing else. On Wed, Nov 19, 2014 at 2:50 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, That sounds good. In terms of System.Web then, would you prefer your internal team does it? or am I ok to start replacing some files when the sub-module is added? I was thinking of trying to hit the HttpApplication class first and work my way out from there. Thanks, Martin On 19 November 2014 19:41, Miguel de Icaza mig...@xamarin.com wrote: Hey, I do not think we would be moving the code. We would do two things: - Make changes to the fork in mono/referencesoure - Reference the new files from mono/external/referencesource Miguel On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: HI Miguel, Thanks, exactly what I've been waiting for! I only really have 1 question. In the ways that we are going to port things, you mention pulling in the entire assembly. How exactly would you be thinking this would work? try building and fixing anything that it depends from other libraries in the other libraries? or are you going to fork the reference source, submodule it, reference all the files in the .sources files within mono, then fix (i.e. add #ifdefs etc.) to the fork? Essentially, are you thinking that there will be an assembly that can simply be copied without changes in the above circumstance? Thanks, Martin On 19 November 2014 17:48, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
I was thinking we just use a perl script ;-) On Wed, Nov 19, 2014 at 5:48 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, Have you come up with a plan on how to implement the resource methodology that's used for strings? i.e. the SR.GetString(SR.Name) type stuff? Are we just going to implement some partial class that we can add extend for each assembly? Theres loads throughout HttpApplication. Thanks, Martin On 19 November 2014 21:02, Martin Thwaites monofo...@my2cents.co.uk wrote: Will do, I'm on Gardening leave for the next week, so I've got sometime to look at it. Do you have an ETA on when the fork will be created and the sub-module added? On 19 November 2014 20:50, Miguel de Icaza mig...@xamarin.com wrote: Hey, Xamarin's team is not likely going to do System.Web, so feel free to step in. I am not sure if we can bring System.Web as a whole yet, I think it is a clear case of something that will have to be done in steps and starting with HttpApplication is as good as an idea as antyhing else. On Wed, Nov 19, 2014 at 2:50 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, That sounds good. In terms of System.Web then, would you prefer your internal team does it? or am I ok to start replacing some files when the sub-module is added? I was thinking of trying to hit the HttpApplication class first and work my way out from there. Thanks, Martin On 19 November 2014 19:41, Miguel de Icaza mig...@xamarin.com wrote: Hey, I do not think we would be moving the code. We would do two things: - Make changes to the fork in mono/referencesoure - Reference the new files from mono/external/referencesource Miguel On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: HI Miguel, Thanks, exactly what I've been waiting for! I only really have 1 question. In the ways that we are going to port things, you mention pulling in the entire assembly. How exactly would you be thinking this would work? try building and fixing anything that it depends from other libraries in the other libraries? or are you going to fork the reference source, submodule it, reference all the files in the .sources files within mono, then fix (i.e. add #ifdefs etc.) to the fork? Essentially, are you thinking that there will be an assembly that can simply be copied without changes in the above circumstance? Thanks, Martin On 19 November 2014 17:48, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
So just replace them with static strings via a script? or create an individual class somewhere and simply add to it as we implement new classes from the referencesource? On 19 November 2014 22:50, Miguel de Icaza mig...@xamarin.com wrote: I was thinking we just use a perl script ;-) On Wed, Nov 19, 2014 at 5:48 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, Have you come up with a plan on how to implement the resource methodology that's used for strings? i.e. the SR.GetString(SR.Name) type stuff? Are we just going to implement some partial class that we can add extend for each assembly? Theres loads throughout HttpApplication. Thanks, Martin On 19 November 2014 21:02, Martin Thwaites monofo...@my2cents.co.uk wrote: Will do, I'm on Gardening leave for the next week, so I've got sometime to look at it. Do you have an ETA on when the fork will be created and the sub-module added? On 19 November 2014 20:50, Miguel de Icaza mig...@xamarin.com wrote: Hey, Xamarin's team is not likely going to do System.Web, so feel free to step in. I am not sure if we can bring System.Web as a whole yet, I think it is a clear case of something that will have to be done in steps and starting with HttpApplication is as good as an idea as antyhing else. On Wed, Nov 19, 2014 at 2:50 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, That sounds good. In terms of System.Web then, would you prefer your internal team does it? or am I ok to start replacing some files when the sub-module is added? I was thinking of trying to hit the HttpApplication class first and work my way out from there. Thanks, Martin On 19 November 2014 19:41, Miguel de Icaza mig...@xamarin.com wrote: Hey, I do not think we would be moving the code. We would do two things: - Make changes to the fork in mono/referencesoure - Reference the new files from mono/external/referencesource Miguel On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: HI Miguel, Thanks, exactly what I've been waiting for! I only really have 1 question. In the ways that we are going to port things, you mention pulling in the entire assembly. How exactly would you be thinking this would work? try building and fixing anything that it depends from other libraries in the other libraries? or are you going to fork the reference source, submodule it, reference all the files in the .sources files within mono, then fix (i.e. add #ifdefs etc.) to the fork? Essentially, are you thinking that there will be an assembly that can simply be copied without changes in the above circumstance? Thanks, Martin On 19 November 2014 17:48, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
The following script: git grep 'SR\.[A-Za-z_]*' | sed -e 's/SR.GetString//' | grep SR. | sed -e 's/.*SR\.//' -e 's/[,)};].*//' | sort | uniq | sed 's/\(.*\)/public const string \1 = \1;/' Generated this: https://gist.github.com/migueldeicaza/d130779095f377cdcf90 On Wed, Nov 19, 2014 at 5:50 PM, Miguel de Icaza mig...@xamarin.com wrote: I was thinking we just use a perl script ;-) On Wed, Nov 19, 2014 at 5:48 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, Have you come up with a plan on how to implement the resource methodology that's used for strings? i.e. the SR.GetString(SR.Name) type stuff? Are we just going to implement some partial class that we can add extend for each assembly? Theres loads throughout HttpApplication. Thanks, Martin On 19 November 2014 21:02, Martin Thwaites monofo...@my2cents.co.uk wrote: Will do, I'm on Gardening leave for the next week, so I've got sometime to look at it. Do you have an ETA on when the fork will be created and the sub-module added? On 19 November 2014 20:50, Miguel de Icaza mig...@xamarin.com wrote: Hey, Xamarin's team is not likely going to do System.Web, so feel free to step in. I am not sure if we can bring System.Web as a whole yet, I think it is a clear case of something that will have to be done in steps and starting with HttpApplication is as good as an idea as antyhing else. On Wed, Nov 19, 2014 at 2:50 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, That sounds good. In terms of System.Web then, would you prefer your internal team does it? or am I ok to start replacing some files when the sub-module is added? I was thinking of trying to hit the HttpApplication class first and work my way out from there. Thanks, Martin On 19 November 2014 19:41, Miguel de Icaza mig...@xamarin.com wrote: Hey, I do not think we would be moving the code. We would do two things: - Make changes to the fork in mono/referencesoure - Reference the new files from mono/external/referencesource Miguel On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: HI Miguel, Thanks, exactly what I've been waiting for! I only really have 1 question. In the ways that we are going to port things, you mention pulling in the entire assembly. How exactly would you be thinking this would work? try building and fixing anything that it depends from other libraries in the other libraries? or are you going to fork the reference source, submodule it, reference all the files in the .sources files within mono, then fix (i.e. add #ifdefs etc.) to the fork? Essentially, are you thinking that there will be an assembly that can simply be copied without changes in the above circumstance? Thanks, Martin On 19 November 2014 17:48, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
Great, so we're going to dump that as a class in the main codebase somewhere? Do we have a place where this sort of thing normally goes? On 19 November 2014 23:09, Miguel de Icaza mig...@xamarin.com wrote: The following script: git grep 'SR\.[A-Za-z_]*' | sed -e 's/SR.GetString//' | grep SR. | sed -e 's/.*SR\.//' -e 's/[,)};].*//' | sort | uniq | sed 's/\(.*\)/public const string \1 = \1;/' Generated this: https://gist.github.com/migueldeicaza/d130779095f377cdcf90 On Wed, Nov 19, 2014 at 5:50 PM, Miguel de Icaza mig...@xamarin.com wrote: I was thinking we just use a perl script ;-) On Wed, Nov 19, 2014 at 5:48 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, Have you come up with a plan on how to implement the resource methodology that's used for strings? i.e. the SR.GetString(SR.Name) type stuff? Are we just going to implement some partial class that we can add extend for each assembly? Theres loads throughout HttpApplication. Thanks, Martin On 19 November 2014 21:02, Martin Thwaites monofo...@my2cents.co.uk wrote: Will do, I'm on Gardening leave for the next week, so I've got sometime to look at it. Do you have an ETA on when the fork will be created and the sub-module added? On 19 November 2014 20:50, Miguel de Icaza mig...@xamarin.com wrote: Hey, Xamarin's team is not likely going to do System.Web, so feel free to step in. I am not sure if we can bring System.Web as a whole yet, I think it is a clear case of something that will have to be done in steps and starting with HttpApplication is as good as an idea as antyhing else. On Wed, Nov 19, 2014 at 2:50 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, That sounds good. In terms of System.Web then, would you prefer your internal team does it? or am I ok to start replacing some files when the sub-module is added? I was thinking of trying to hit the HttpApplication class first and work my way out from there. Thanks, Martin On 19 November 2014 19:41, Miguel de Icaza mig...@xamarin.com wrote: Hey, I do not think we would be moving the code. We would do two things: - Make changes to the fork in mono/referencesoure - Reference the new files from mono/external/referencesource Miguel On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: HI Miguel, Thanks, exactly what I've been waiting for! I only really have 1 question. In the ways that we are going to port things, you mention pulling in the entire assembly. How exactly would you be thinking this would work? try building and fixing anything that it depends from other libraries in the other libraries? or are you going to fork the reference source, submodule it, reference all the files in the .sources files within mono, then fix (i.e. add #ifdefs etc.) to the fork? Essentially, are you thinking that there will be an assembly that can simply be copied without changes in the above circumstance? Thanks, Martin On 19 November 2014 17:48, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-list] .NET and Mono integration, the plans
Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET and Mono integration, the plans
Great, good strategy. William Ivanski 2014-11-19 15:48 GMT-02:00 Miguel de Icaza mig...@xamarin.com: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ 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
[Mono-list] .NET API documentation
This deserves to be cross-posted. I had heard many people express concern about mono and the .NET API, in the wake of oracle v google, and especially in the recent-ish reversal of decision, which now rules an API to be copyrightable. Congratulations to Mono, and the people named by Miguel below, and thank you Microsoft. :-) And congratulations to Oracle, for continuing to destroy java like a bunch of idiots. -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of Miguel de Icaza Sent: Wednesday, May 28, 2014 12:41 PM To: mono-devel Subject: [Mono-dev] .NET API documentation Hello guys, Today we launched Xamarin 3, and as part of this release, we are announcing a big contribution from Microsoft. Microsoft has released the .NET API documentation under a Creative Commons license. This means a few things: • Mono now has complete docs for use on Mac and Linux • MonoDevelop and Xamarin Studio will now provide full docs during code- completion while editing the source code. Many thanks should go to Bryan Costanich that nursed this process and to our friends at Microsoft that made this possible. Including Scott Guthrie, S Somasegar, Richard Lander and everyone that did the work to get us the bits. The documentation is checked into mono/mcs/class, on their respective assemblies. While we have imported most of the documentation now, our importing tools still fail in a handful of cases, so you will see the documentation get more and more in shape in the next couple of weeks. We will also start to integrate the various off-line samples that are part of the documentation. Cheers! Miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET API documentation
Great news! Em qua 28 maio 2014, às 22:42:45, Edward Ned Harvey escreveu: This deserves to be cross-posted. I had heard many people express concern about mono and the .NET API, in the wake of oracle v google, and especially in the recent-ish reversal of decision, which now rules an API to be copyrightable. Congratulations to Mono, and the people named by Miguel below, and thank you Microsoft. :-) And congratulations to Oracle, for continuing to destroy java like a bunch of idiots. -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of Miguel de Icaza Sent: Wednesday, May 28, 2014 12:41 PM To: mono-devel Subject: [Mono-dev] .NET API documentation Hello guys, Today we launched Xamarin 3, and as part of this release, we are announcing a big contribution from Microsoft. Microsoft has released the .NET API documentation under a Creative Commons license. This means a few things: • Mono now has complete docs for use on Mac and Linux • MonoDevelop and Xamarin Studio will now provide full docs during code- completion while editing the source code. Many thanks should go to Bryan Costanich that nursed this process and to our friends at Microsoft that made this possible. Including Scott Guthrie, S Somasegar, Richard Lander and everyone that did the work to get us the bits. The documentation is checked into mono/mcs/class, on their respective assemblies. While we have imported most of the documentation now, our importing tools still fail in a handful of cases, so you will see the documentation get more and more in shape in the next couple of weeks. We will also start to integrate the various off-line samples that are part of the documentation. Cheers! Miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- William Ivanski ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] .NET 4.5.1 + MVC 5
Hi everyone, I currently have a site running on ASP.NET 4.0 and MVC 4. I'd like to upgrade it to ASP.NET 4.5.1 and MVC 5. I tried upgrading the site, and get the following error message when I access it: System.TypeLoadExceptionCould not load type 'System.Web.UnvalidatedRequestValuesBase' from assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. *Description:* HTTP 500.Error processing request. *Details:* Non-web exception. Exception origin (name of application or object): System.Web.Mvc. *Exception stack trace:* at System.Web.Mvc.FormValueProviderFactory.GetValueProvider (System.Web.Mvc.ControllerContext controllerContext) [0x0] in filename unknown:0 at System.Web.Mvc.ValueProviderFactoryCollection.GetValueProvider (System.Web.Mvc.ControllerContext controllerContext) [0x0] in filename unknown:0 at System.Web.Mvc.ControllerBase.get_ValueProvider () [0x0] in filename unknown:0 at System.Web.Mvc.ControllerActionInvoker.GetParameterValue (System.Web.Mvc.ControllerContext controllerContext, System.Web.Mvc.ParameterDescriptor parameterDescriptor) [0x0] in filename unknown:0 at System.Web.Mvc.ControllerActionInvoker.GetParameterValues (System.Web.Mvc.ControllerContext controllerContext, System.Web.Mvc.ActionDescriptor actionDescriptor) [0x0] in filename unknown:0 at System.Web.Mvc.Async.AsyncControllerActionInvoker+c__DisplayClass1e.BeginInvokeActionb__16 (System.AsyncCallback asyncCallback, System.Object asyncState) [0x0] in filename unknown:0 Is there a workaround for this issue, like a Web.config flag? Thanks! ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net versions ... compatibility history
From: mono-list-boun...@lists.ximian.com [mailto:mono-list- boun...@lists.ximian.com] On Behalf Of Stifu Keep in mind that just because a certain Mono version supports a certain .NET profile, doesn't mean it fully supports everything in that profile. For example, Mono 2.0 supports .NET 2.0 and 3.5, but has many missing 3.5 bits. Even the latest Mono versions do not support all the APIs .NET does. So things are not as simple as deciding which .NET version you want to support. By the way, check out the Mono wikipedia page: http://en.wikipedia.org/wiki/Mono_%28software%29#History It may give you the overview you're looking for. It says Mono 1.2 supports C# 2.0, but that the APIs are not on par with .NET 2.0 until Mono 2.0. Ahh. I was understanding before, that any given mono version is not 100% compatible with any particular .Net version, but perhaps I wasn't understanding well enough... Here's my new perception - The goal is to develop some applications cross-platform compatible (specifically, windows, mac, ubuntu, centos). It is understood that the application for each platform will be a separate product, we can't just reuse all the code and expect it to work on another platform. But we'd like to maximize the code reuse. It's understood, the only way to do this is to start developing on one platform, and obsessively frequently test the code on multiple platforms. The goal is to minimize the incompatibilities between platforms... So I guess the best approach is ... First of all, start with .Net 3.5 on windows. Expect most of it to work on mac, ubuntu, and centos 6. But don't hold high hopes for centos 5. Test obsessively, with every little change. Sound about right? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net versions ... compatibility history
Sounds good. Even better if the tests are automated, so you can just run them on each OS (using NUnit and/or other test frameworks). Note that the application doesn't have to be a separate product for each OS. It depends on your app. Just check first that you're not planning to use big .NET APIs that are not supported in Mono. Another idea if you want to be safer and minimize possible surprises: develop with Mono, then test with .NET. Again, whether this is a good idea or not depends on your app. edward.harvey.mono wrote From: mono-list-bounces@.ximian [mailto:mono-list- bounces@.ximian] On Behalf Of Stifu Keep in mind that just because a certain Mono version supports a certain .NET profile, doesn't mean it fully supports everything in that profile. For example, Mono 2.0 supports .NET 2.0 and 3.5, but has many missing 3.5 bits. Even the latest Mono versions do not support all the APIs .NET does. So things are not as simple as deciding which .NET version you want to support. By the way, check out the Mono wikipedia page: http://en.wikipedia.org/wiki/Mono_%28software%29#History It may give you the overview you're looking for. It says Mono 1.2 supports C# 2.0, but that the APIs are not on par with .NET 2.0 until Mono 2.0. Ahh. I was understanding before, that any given mono version is not 100% compatible with any particular .Net version, but perhaps I wasn't understanding well enough... Here's my new perception - The goal is to develop some applications cross-platform compatible (specifically, windows, mac, ubuntu, centos). It is understood that the application for each platform will be a separate product, we can't just reuse all the code and expect it to work on another platform.But we'd like to maximize the code reuse. It's understood, the only way to do this is to start developing on one platform, and obsessively frequently test the code on multiple platforms. The goal is to minimize the incompatibilities between platforms... So I guess the best approach is ... First of all, start with .Net 3.5 on windows. Expect most of it to work on mac, ubuntu, and centos 6. But don't hold high hopes for centos 5. Test obsessively, with every little change. Sound about right? ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Net-versions-compatibility-history-tp4650745p4650786.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net versions ... compatibility history
In my experience, if you don't stray to far away from the core framework, you are in very good shape with API support. Stay away from things like Entity Framework and WPF (completely unsupported), use things like WCF and server components should be done with caution, but LINQ, TPL, or other parts of the core framework have very robust and well-tested implementations and you are much less likely to encounter issues. Of course you should test, and particularly load test, across platforms as some of the internals work a little differently and bugs can pop up in unexpected scenarios. As far as the runtime version included in various Linux distributions, in many cases it is better to package the runtime with your application. RHEL / CentOS have an old mono distribution by way of the EPEL repository and by nature, that distribution uses older software versions. This isn't just a mono constraint; if you have a python application that relies on python 2.4 (which is from 2006), then you need to package your own python to distribute to RHEL / CentOS. I wouldn't let the OS dictate the runtime you should use if it is simply a matter of packaging a newer runtime with your application. The OS can only really dictate the shared runtime version. On Aug 7, 2012, at 7:41 AM, edward.harvey.mono wrote: From: mono-list-boun...@lists.ximian.com [mailto:mono-list- boun...@lists.ximian.com] On Behalf Of Stifu Keep in mind that just because a certain Mono version supports a certain .NET profile, doesn't mean it fully supports everything in that profile. For example, Mono 2.0 supports .NET 2.0 and 3.5, but has many missing 3.5 bits. Even the latest Mono versions do not support all the APIs .NET does. So things are not as simple as deciding which .NET version you want to support. By the way, check out the Mono wikipedia page: http://en.wikipedia.org/wiki/Mono_%28software%29#History It may give you the overview you're looking for. It says Mono 1.2 supports C# 2.0, but that the APIs are not on par with .NET 2.0 until Mono 2.0. Ahh. I was understanding before, that any given mono version is not 100% compatible with any particular .Net version, but perhaps I wasn't understanding well enough... Here's my new perception - The goal is to develop some applications cross-platform compatible (specifically, windows, mac, ubuntu, centos). It is understood that the application for each platform will be a separate product, we can't just reuse all the code and expect it to work on another platform.But we'd like to maximize the code reuse. It's understood, the only way to do this is to start developing on one platform, and obsessively frequently test the code on multiple platforms. The goal is to minimize the incompatibilities between platforms... So I guess the best approach is ... First of all, start with .Net 3.5 on windows. Expect most of it to work on mac, ubuntu, and centos 6. But don't hold high hopes for centos 5. Test obsessively, with every little change. Sound about right? ___ 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] .Net versions ... compatibility history
For the record: Entity Framework has been open sourced, and Mono will probably support it soon. Dave Curylo wrote In my experience, if you don't stray to far away from the core framework, you are in very good shape with API support. Stay away from things like Entity Framework and WPF (completely unsupported), use things like WCF and server components should be done with caution, but LINQ, TPL, or other parts of the core framework have very robust and well-tested implementations and you are much less likely to encounter issues. Of course you should test, and particularly load test, across platforms as some of the internals work a little differently and bugs can pop up in unexpected scenarios. As far as the runtime version included in various Linux distributions, in many cases it is better to package the runtime with your application. RHEL / CentOS have an old mono distribution by way of the EPEL repository and by nature, that distribution uses older software versions. This isn't just a mono constraint; if you have a python application that relies on python 2.4 (which is from 2006), then you need to package your own python to distribute to RHEL / CentOS. I wouldn't let the OS dictate the runtime you should use if it is simply a matter of packaging a newer runtime with your application. The OS can only really dictate the shared runtime version. On Aug 7, 2012, at 7:41 AM, edward.harvey.mono wrote: From: mono-list-bounces@.ximian [mailto:mono-list- bounces@.ximian] On Behalf Of Stifu Keep in mind that just because a certain Mono version supports a certain .NET profile, doesn't mean it fully supports everything in that profile. For example, Mono 2.0 supports .NET 2.0 and 3.5, but has many missing 3.5 bits. Even the latest Mono versions do not support all the APIs .NET does. So things are not as simple as deciding which .NET version you want to support. By the way, check out the Mono wikipedia page: http://en.wikipedia.org/wiki/Mono_%28software%29#History It may give you the overview you're looking for. It says Mono 1.2 supports C# 2.0, but that the APIs are not on par with .NET 2.0 until Mono 2.0. Ahh. I was understanding before, that any given mono version is not 100% compatible with any particular .Net version, but perhaps I wasn't understanding well enough... Here's my new perception - The goal is to develop some applications cross-platform compatible (specifically, windows, mac, ubuntu, centos). It is understood that the application for each platform will be a separate product, we can't just reuse all the code and expect it to work on another platform.But we'd like to maximize the code reuse. It's understood, the only way to do this is to start developing on one platform, and obsessively frequently test the code on multiple platforms. The goal is to minimize the incompatibilities between platforms... So I guess the best approach is ... First of all, start with .Net 3.5 on windows. Expect most of it to work on mac, ubuntu, and centos 6. But don't hold high hopes for centos 5. Test obsessively, with every little change. Sound about right? ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Net-versions-compatibility-history-tp4650745p4650789.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net versions ... compatibility history
It would be the definive way to have an attractive option to non mono coders. /Gabriel -Original Message- From: Stifu st...@free.fr Date: Tue, 7 Aug 2012 15:02:32 To: mono-list@lists.ximian.com Subject: Re: [Mono-list] .Net versions ... compatibility history For the record: Entity Framework has been open sourced, and Mono will probably support it soon. Dave Curylo wrote In my experience, if you don't stray to far away from the core framework, you are in very good shape with API support. Stay away from things like Entity Framework and WPF (completely unsupported), use things like WCF and server components should be done with caution, but LINQ, TPL, or other parts of the core framework have very robust and well-tested implementations and you are much less likely to encounter issues. Of course you should test, and particularly load test, across platforms as some of the internals work a little differently and bugs can pop up in unexpected scenarios. As far as the runtime version included in various Linux distributions, in many cases it is better to package the runtime with your application. RHEL / CentOS have an old mono distribution by way of the EPEL repository and by nature, that distribution uses older software versions. This isn't just a mono constraint; if you have a python application that relies on python 2.4 (which is from 2006), then you need to package your own python to distribute to RHEL / CentOS. I wouldn't let the OS dictate the runtime you should use if it is simply a matter of packaging a newer runtime with your application. The OS can only really dictate the shared runtime version. On Aug 7, 2012, at 7:41 AM, edward.harvey.mono wrote: From: mono-list-bounces@.ximian [mailto:mono-list- bounces@.ximian] On Behalf Of Stifu Keep in mind that just because a certain Mono version supports a certain .NET profile, doesn't mean it fully supports everything in that profile. For example, Mono 2.0 supports .NET 2.0 and 3.5, but has many missing 3.5 bits. Even the latest Mono versions do not support all the APIs .NET does. So things are not as simple as deciding which .NET version you want to support. By the way, check out the Mono wikipedia page: http://en.wikipedia.org/wiki/Mono_%28software%29#History It may give you the overview you're looking for. It says Mono 1.2 supports C# 2.0, but that the APIs are not on par with .NET 2.0 until Mono 2.0. Ahh. I was understanding before, that any given mono version is not 100% compatible with any particular .Net version, but perhaps I wasn't understanding well enough... Here's my new perception - The goal is to develop some applications cross-platform compatible (specifically, windows, mac, ubuntu, centos). It is understood that the application for each platform will be a separate product, we can't just reuse all the code and expect it to work on another platform. But we'd like to maximize the code reuse. It's understood, the only way to do this is to start developing on one platform, and obsessively frequently test the code on multiple platforms. The goal is to minimize the incompatibilities between platforms... So I guess the best approach is ... First of all, start with .Net 3.5 on windows. Expect most of it to work on mac, ubuntu, and centos 6. But don't hold high hopes for centos 5. Test obsessively, with every little change. Sound about right? ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Net-versions-compatibility-history-tp4650745p4650789.html Sent from the Mono - General mailing list archive at Nabble.com. ___ 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] .Net versions ... compatibility history
From: mono-list-boun...@lists.ximian.com [mailto:mono-list- boun...@lists.ximian.com] On Behalf Of Stifu I don't know of documentation for this, but Mono 2.4 is old, and I wouldn't bother trying to support anything older. If we wish to develop distribute a server product using mono... It would be good to support rhel 5 6, as well as the various ubuntu LTS. Right now, ubuntu LTS all seem to have mono 2.10, which is good. But ... But centos 5 (epel5) has mono 1.2.4, and centos 6 (epel6) has mono 2.4.3. Maybe we'll just have to drop centos5 as a supported platform, but if you are a business distributing a product, telling your customers that you can only support the very latest OS, it makes it difficult for the customers to accept your product... Just ask any sysadmin who supports apple products. ;-) The day a new OS is released, the old OS is unsupported, so you as a company are forced to immediately drop what you're doing and test the new OS, as if the mac product release cycle is the only important thing in your life. ;-) Anyway... I know mono 1.2.4 is old. But what version of .Net is it compatible with? We may decide we're able to develop everything we need to develop, using that version... Or we may just drop support for centos5. I can't envision us saying we'll support ubuntu only and not redhat... Which means we're already limited to a maximum .Net 3.5. Thanks again... ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net versions ... compatibility history
Keep in mind that just because a certain Mono version supports a certain .NET profile, doesn't mean it fully supports everything in that profile. For example, Mono 2.0 supports .NET 2.0 and 3.5, but has many missing 3.5 bits. Even the latest Mono versions do not support all the APIs .NET does. So things are not as simple as deciding which .NET version you want to support. By the way, check out the Mono wikipedia page: http://en.wikipedia.org/wiki/Mono_%28software%29#History It may give you the overview you're looking for. It says Mono 1.2 supports C# 2.0, but that the APIs are not on par with .NET 2.0 until Mono 2.0. edward.harvey.mono wrote From: mono-list-bounces@.ximian [mailto:mono-list- bounces@.ximian] On Behalf Of Stifu I don't know of documentation for this, but Mono 2.4 is old, and I wouldn't bother trying to support anything older. If we wish to develop distribute a server product using mono... It would be good to support rhel 5 6, as well as the various ubuntu LTS. Right now, ubuntu LTS all seem to have mono 2.10, which is good. But ... But centos 5 (epel5) has mono 1.2.4, and centos 6 (epel6) has mono 2.4.3. Maybe we'll just have to drop centos5 as a supported platform, but if you are a business distributing a product, telling your customers that you can only support the very latest OS, it makes it difficult for the customers to accept your product... Just ask any sysadmin who supports apple products. ;-) The day a new OS is released, the old OS is unsupported, so you as a company are forced to immediately drop what you're doing and test the new OS, as if the mac product release cycle is the only important thing in your life. ;-) Anyway... I know mono 1.2.4 is old. But what version of .Net is it compatible with? We may decide we're able to develop everything we need to develop, using that version... Or we may just drop support for centos5. I can't envision us saying we'll support ubuntu only and not redhat... Which means we're already limited to a maximum .Net 3.5. Thanks again... ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Net-versions-compatibility-history-tp4650745p4650765.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] .Net versions ... compatibility history
I see on the compatibility page, that the current release is 2.10.8, and it is compatible with .Net 4.0. But what about older versions? The current mono distributed with amazon linux is 2.4.3.1-4... Is it also compatible with .Net 4.0? Or perhaps something older? I'm basically looking for the history of the Compatibility page. Thanks... ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net versions ... compatibility history
Mono 2.4.x is compatible with .NET from 1.0 to 3.5. With Mono 2.8, the .NET 1.x profile was dropped, and the 4.0 one was added. edward.harvey.mono wrote I see on the compatibility page, that the current release is 2.10.8, and it is compatible with .Net 4.0. But what about older versions? The current mono distributed with amazon linux is 2.4.3.1-4... Is it also compatible with .Net 4.0? Or perhaps something older? I'm basically looking for the history of the Compatibility page. Thanks... ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Net-versions-compatibility-history-tp4650745p4650747.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net versions ... compatibility history
From: mono-list-boun...@lists.ximian.com [mailto:mono-list- boun...@lists.ximian.com] On Behalf Of Stifu Mono 2.4.x is compatible with .NET from 1.0 to 3.5. With Mono 2.8, the .NET 1.x profile was dropped, and the 4.0 one was added. Thank you. But I expect we'll want to know which platforms our application will run on, and we'll want to be designing with these considerations in mind... Is this documented somewhere? What if I want to find this answer for ubuntu, or an older version of redhat, or fedora, etc...? I am guessing, somewhere in the source code, there's a readme that says compatible with .Net version ___ And I can certainly go fetch all the different versions of source code and create an index... But I'm guessing there's a summary already written somewhere, or an easier way to do it, right? Thanks again... ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net versions ... compatibility history
I don't know of documentation for this, but Mono 2.4 is old, and I wouldn't bother trying to support anything older. Besides, it'd be a pain to test compatibility with so many frameworks, many bugs got fixed since then, etc. Mono developers and users tend to use recent versions of the framework. Just ask your users to upgrade if necessary. Otherwise, your development costs will skyrocket, and your development team will be frustrated. :) Anyway, from what you're saying, it sounds like you'd like to go for either the 2.0 or 3.5 profile. edward.harvey.mono wrote From: mono-list-bounces@.ximian [mailto:mono-list- bounces@.ximian] On Behalf Of Stifu Mono 2.4.x is compatible with .NET from 1.0 to 3.5. With Mono 2.8, the .NET 1.x profile was dropped, and the 4.0 one was added. Thank you. But I expect we'll want to know which platforms our application will run on, and we'll want to be designing with these considerations in mind... Is this documented somewhere? What if I want to find this answer for ubuntu, or an older version of redhat, or fedora, etc...? I am guessing, somewhere in the source code, there's a readme that says compatible with .Net version ___ And I can certainly go fetch all the different versions of source code and create an index... But I'm guessing there's a summary already written somewhere, or an easier way to do it, right? Thanks again... ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Net-versions-compatibility-history-tp4650745p4650757.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET libraries
Hi, Your DLL may work if: - It's fully managed (all .NET, no native code / P/Invokes) - It doesn't have Windows-specific bits (hard-coded paths, etc) - It doesn't hit Mono-specific bugs or unimplemented stuff That said, if it fails, I'd usually expect it to fail at run time, not at compile time. Might be a Mono C# compiler bug (I guess it should at least fail gracefully, no matter what). fala70 wrote: Hi, Can I used dll .NET libraries builded under windows, and using them on Mono Project under Mac ? I am trying to do that, but I can't compile I receive the error: Error - 9.00.41 - C# compiler crashed. Response file '/var/folders/m1/lfz2vfhd235g8rks4bhvlw18gn/T/tmp71460652.tmp', stdout file '/var/folders/m1/lfz2vfhd235g8rks4bhvlw18gn/T/tmp45dc0931.tmp', stderr file '/var/folders/m1/lfz2vfhd235g8rks4bhvlw18gn/T/tmp199e4728.tmp' -- View this message in context: http://mono.1490590.n4.nabble.com/NET-libraries-tp3877288p3877345.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .net on a Mac
spipes wrote: I know that this site deals with more knowledgeable users than I, but I wonder if anyone could help me with the dilemma I am facing: trying to use a .net site on a Mac. I have installed Mono, restarted my machine, yet see no difference when I visit the site in question. Is there some further step I must take? Thank you in advance for your assistance. Mono has nothing to do with making .NET-based Web sites visible in a Web browser. You want to check your Internet connection. Or maybe the site needs a browser plug-in like Silverlight (get it from Microsoft) or Flash (which has nothing to do with .NET). -- View this message in context: http://mono.1490590.n4.nabble.com/net-on-a-Mac-tp3161605p3161969.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .net on a Mac
I guess I was mislead then, for I was told that Mono would enable me to properly view the site/app in question. I have both Silverlight and Flash, but this does not help with the Mac compatibility with the Frames in .Net. -- View this message in context: http://mono.1490590.n4.nabble.com/net-on-a-Mac-tp3161605p3162784.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .net on a Mac
I'm confused. And I think you are, too. :) If it's a site, you don't need .NET / Mono on the client side, only on the server, right? spipes wrote: I know that this site deals with more knowledgeable users than I, but I wonder if anyone could help me with the dilemma I am facing: trying to use a .net site on a Mac. I have installed Mono, restarted my machine, yet see no difference when I visit the site in question. Is there some further step I must take? Thank you in advance for your assistance. -- View this message in context: http://mono.1490590.n4.nabble.com/net-on-a-Mac-tp3161605p3161727.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] NET Compact Framework Assembly on Mono
goingmono wrote: I have a assembly built for the .NET Compact Framework 2 that uses Windows.Forms (Compact) When I load this assembly from a full .Net application on MS Windows it automatically uses the full .Net Framework Windows.Forms and on PocketPC the Compact .Net Framework. Mono seems to get confused (I think it does not know about the Windows.Forms public key ..) It seems to be looking for the Compact Windows.Forms assembly and cannot find it. have you had any luck working this out? i've also got .net compact framework application that fails with this error: Could not load file or assembly 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=969db8053d3322ac , Retargetable=Yes' or one of its dependencies. The entry point method could not be loaded the publickeytoken is different for .net CF compared to full .net framework, perhaps this is source of the problem (i.e. mono is not aware of .net CF assemblies?) Peter -- View this message in context: http://mono.1490590.n4.nabble.com/NET-Compact-Framework-Assembly-on-Mono-tp1507389p3026501.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] .Net exe window not fully viewable with mono
Hi, I am using mono to open .Net exe's on Ubuntu Lucid Lynx. I am able to open the exes. But I am not able to view/use the full window. The window is made short. Certain buttons and other controls at the bottom of the window are not viewable. I could use the buttons by tabbing and pressing space. It is not possible to use other controls like textboxes. Also, the maximize button is not available and the window is not resizable. I use mono filename.exe to run the .Net exes. Are there any params I can use with this command to get a bigger window. The mono version I am using is 2.6.3. Thanks in Advance. Regards Naveen.S -- View this message in context: http://mono.1490590.n4.nabble.com/Net-exe-window-not-fully-viewable-with-mono-tp2279242p2279242.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net exe window not fully viewable with mono
Is this something that happens with all apps, or only a certain one? If it's the latter, you can try this: http://mono-project.com/FAQ:_Winforms#My_forms_are_sized_improperly naveenyes wrote: Hi, I am using mono to open .Net exe's on Ubuntu Lucid Lynx. I am able to open the exes. But I am not able to view/use the full window. The window is made short. Certain buttons and other controls at the bottom of the window are not viewable. I could use the buttons by tabbing and pressing space. It is not possible to use other controls like textboxes. Also, the maximize button is not available and the window is not resizable. I use mono filename.exe to run the .Net exes. Are there any params I can use with this command to get a bigger window. The mono version I am using is 2.6.3. Thanks in Advance. Regards Naveen.S -- View this message in context: http://mono.1490590.n4.nabble.com/Net-exe-window-not-fully-viewable-with-mono-tp2279242p2279265.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net exe window not fully viewable with mono
Thanks Stifu, Thanks for the quick reply. I am experiencing this problem with all the exes. Actually I am trying to run third party .Net exes (not developed by me). I tried with 2 exes and they both had sizing issues. I tried the link you suggested, but it did not work for me. Thanks again. -- View this message in context: http://mono.1490590.n4.nabble.com/Net-exe-window-not-fully-viewable-with-mono-tp2279242p2279586.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net exe window not fully viewable with mono
Well then, I don't know what to suggest, other than sharing these programs so I can check them out and tell you what I see. naveenyes wrote: Thanks Stifu, Thanks for the quick reply. I am experiencing this problem with all the exes. Actually I am trying to run third party .Net exes (not developed by me). I tried with 2 exes and they both had sizing issues. I tried the link you suggested, but it did not work for me. Thanks again. -- View this message in context: http://mono.1490590.n4.nabble.com/Net-exe-window-not-fully-viewable-with-mono-tp2279242p2279762.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] .Net based report generation on windows and linux without installed office applications
Dear Developers, I would like to ask for some information you if you know about a program that runs on linux (so can be developped with mono) or is a cross-platform program managing to generate a report of spreadsheets or documents, and if the program can run without having an office installed on the PC? Thanks, Attila -- View this message in context: http://old.nabble.com/.Net-based-report-generation-on-windows-and-linux-without-installed-office-applications-tp27358291p27358291.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net based report generation on windows and linux without installed office applications
You may try http://myxls.in2bits.org/ http://myxls.in2bits.org/ for binary (*.xls) Excel spreadsheets or http://odftoolkit.org/projects/aodl http://odftoolkit.org/projects/aodl for ODF documents. Good luck with your project. Attila816 wrote: Dear Developers, I would like to ask for some information you if you know about a program that runs on linux (so can be developped with mono) or is a cross-platform program managing to generate a report of spreadsheets or documents, and if the program can run without having an office installed on the PC? Thanks, Attila -- View this message in context: http://old.nabble.com/.Net-based-report-generation-on-windows-and-linux-without-installed-office-applications-tp27358291p27358767.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net based report generation on windows and linux without installed office applications
Try http://fyireporting.com most advanced .Net based RDL reporting solution , Report designer, viewer, SilverLight XAML engine included. This engine can also used to implement missing .NET reporting services assemblies and report designer in MONO. Andrus. - Original Message - From: Dimitar Dobrev dpldob...@yahoo.com To: mono-list@lists.ximian.com Sent: Thursday, January 28, 2010 8:46 PM Subject: Re: [Mono-list] .Net based report generation on windows and linux without installed office applications You may try http://myxls.in2bits.org/ http://myxls.in2bits.org/ for binary (*.xls) Excel spreadsheets or http://odftoolkit.org/projects/aodl http://odftoolkit.org/projects/aodl for ODF documents. Good luck with your project. Attila816 wrote: Dear Developers, I would like to ask for some information you if you know about a program that runs on linux (so can be developped with mono) or is a cross-platform program managing to generate a report of spreadsheets or documents, and if the program can run without having an office installed on the PC? Thanks, Attila -- View this message in context: http://old.nabble.com/.Net-based-report-generation-on-windows-and-linux-without-installed-office-applications-tp27358291p27358767.html Sent from the Mono - General mailing list archive at Nabble.com. ___ 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
[Mono-list] .NET Reflector and Mono compatibility
Hi everyone,
I'm writing because I want to give you a heads up about a problem we’ve
discovered with Mono compatibility in the new version of .NET Reflector, due
to be released in February.
At PDC back in November I assured the Mono guys we met that we would
continue to support running on Mono with .NET Reflector 6, though not .NET
Reflector Pro, since the Pro functionality is part of the Visual Studio
add-in. This is still my intention in the longer term. Unfortunately just
before Christmas we discovered a problem with our obfuscation that breaks
compatibility with Mono in builds of .NET Reflector 6, and we can't go back
to the old protection scheme due to other changes we've made.
At the end of summer last year we acquired the {smartassembly} obfuscator,
and we've been using it to protect .NET Reflector for the past two months or
so, which is what has caused the problem. As part of a larger batch of
updates and fixes, we're going to patch {smartassembly} so that it doesn't
cause compatibility problems with Mono, so this won't come up again.
Unfortunately those fixes won't be available before .NET Reflector 6 is due
to be released but, in the meantime, I'm anxious not to leave Mono users out
in the cold, without a working build of .NET Reflector, so I propose the
following:
(1)We will release .NET Reflector 6/.NET Reflector Pro in its current
form, without Mono compatibility, towards the end of February.
(2)At the same time, we will release a build of .NET Reflector that will
only run on Mono. This will probably be version 5.1.7.0. This will be
identical to the current 5.1.6.0 release, apart from the fact that it will
only work on Mono. It won’t contain any of the bug fixes we’ve added to
version 6, and it obviously won’t contain any of the Pro functionality in
the Visual Studio add-in, but it will do everything that the current 5.1.6.0
release can do.
(3)We’ll make both builds available from the Red Gate website, and we’ll
add a sticky to our support forum about the Mono-compatible build, just in
case people miss the download link on the website.
Let me emphasise that this is something I regard only as an interim
solution. As soon as we’re in a position to do so, we’ll put out a 6.x build
that is protected by {smartassembly}, and will work with Mono, and thus Mono
users will get the benefit of the bug fixes we’ve added to the v6 release.
If you have any comments or feedback about this, please let me know.
Thanks,
Bart Read
.NET Tools Product Manager
Red Gate Software Ltd
--
View this message in context:
http://old.nabble.com/.NET-Reflector-and-Mono-compatibility-tp27014162p27014162.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] .net compact framework
As can be used to program in monodevelop for . NET Compact Framework -- View this message in context: http://www.nabble.com/.net-compact-framework-tp24479968p24479968.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] .net remoting: secure channel with secure=true
Can someone tell me if mono support encryption and authentication like .net 2.0 does ? by adding in configuration file, secure=true on both client and server -- View this message in context: http://www.nabble.com/.net-remoting%3A-secure--channel-with-secure%3D%22true%22-tp21687633p21687633.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .net remoting problem with object sending
I'm all so having problems with it. I get: Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Client' or one of its dependencies. The system cannot find the file specified. File name: 'Client' at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception exc, System.Object[] out_args) [0x00185] in /build/buildd/mono-1.9.1+dfsg/mcs/class/corlib/System.Runtime.Remoting.Proxies/RealProxy.cs:227 I did follow a tutorial http://www.codeproject.com/KB/IP/csremoteevents1.aspx?msg=2740979 link to tutorial . Any ideas? Lluis Sanchez wrote: The problem is that the receiver application can't deserialize the object because it can't find the assembly that implements it. In any case, remoting should not crash with a null ref exception. I just fixed it. Lluis. El dc 28 de 02 del 2007 a les 04:40 +0100, en/na Mirek Binas va escriure: hello i am trying to develop application with .net remoting for communication. at the moment - everything is well, but when i want to send object, that is not one of the default types, the exception raised: Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object the object is not null (checked line before call of the remote method). and in the declaration of the class it is marked as [Serializable]. don't know, what is the problem about. any idea? mirek p.s.: the complete exception Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object Server stack trace: at System.Runtime.Remoting.Channels.SimpleBinder.BindToType (System.String assemblyName, System.String typeName) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapTypeMapper.GetType (System.String xmlName, System.String xmlNamespace) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapReader.Deserialize () [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapReader.Deserialize (System.IO.Stream inStream, ISoapMessage soapMessage) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize (System.IO.Stream serializationStream) [0x0] at System.Runtime.Remoting.Channels.SoapServerFormatterSink.ProcessMessage (IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, System.IO.Stream requestStream, IMessage responseMsg, ITransportHeaders responseHeaders, System.IO.Stream responseStream) [0x0] Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception exc, System.Object[] out_args) [0x0] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://www.nabble.com/.net-remoting-problem-with-object-sending-tp9197526p19687572.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .net remoting problem with object sending
cmare wrote: I'm all so having problems with it. I get: Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Client' or one of its dependencies. The system cannot find the file specified. File name: 'Client' at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception exc, System.Object[] out_args) [0x00185] in /build/buildd/mono-1.9.1+dfsg/mcs/class/corlib/System.Runtime.Remoting.Proxies/RealProxy.cs:227 I did follow a tutorial http://www.codeproject.com/KB/IP/csremoteevents1.aspx?msg=2740979 link to tutorial . Any ideas? Yes. Please file a bug with a self-contained test case at http://www.mono-project.com/Bugs. Robert Lluis Sanchez wrote: The problem is that the receiver application can't deserialize the object because it can't find the assembly that implements it. In any case, remoting should not crash with a null ref exception. I just fixed it. Lluis. El dc 28 de 02 del 2007 a les 04:40 +0100, en/na Mirek Binas va escriure: hello i am trying to develop application with .net remoting for communication. at the moment - everything is well, but when i want to send object, that is not one of the default types, the exception raised: Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object the object is not null (checked line before call of the remote method). and in the declaration of the class it is marked as [Serializable]. don't know, what is the problem about. any idea? mirek p.s.: the complete exception Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object Server stack trace: at System.Runtime.Remoting.Channels.SimpleBinder.BindToType (System.String assemblyName, System.String typeName) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapTypeMapper.GetType (System.String xmlName, System.String xmlNamespace) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapReader.Deserialize () [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapReader.Deserialize (System.IO.Stream inStream, ISoapMessage soapMessage) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize (System.IO.Stream serializationStream) [0x0] at System.Runtime.Remoting.Channels.SoapServerFormatterSink.ProcessMessage (IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, System.IO.Stream requestStream, IMessage responseMsg, ITransportHeaders responseHeaders, System.IO.Stream responseStream) [0x0] Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception exc, System.Object[] out_args) [0x0] ___ 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
[Mono-list] .Net output works in XSP2 not Apache2/mod_mono
Hi,
I've got some file download code that works just fine under XSP2
( outputs the file ok, and user can open it up ) but under Apache2/
Mod_Mono (Apache/2.2.4 (Ubuntu 7.10)) mod_mono/1.2.6) it truncates
the file to zero. I've checked permissions, etc... and can't seem to
come up with any ideas as to why this is. There's no errors in the
logs either.
File output code is:
private bool DownloadFile(string sFileId)
{
bool bRetValue = false;
try
{
FileService FService = new FileService();
FileStorage DownloadFile = FService.GetFileById
(Int16.Parse(sFileId));
string sFileName = pGeneral.GetBaseFilePath() + \\ +
DownloadFile.Path;
Response.Clear();
Response.ClearContent();
Response.ClearHeaders();
this.EnableViewState = false;
Response.Buffer = true;
Response.ContentType = application/octet-stream;
Response.Charset = utf-8; //UTF8
Response.AddHeader(Content-Disposition, attachment;
filename= + DownloadFile.FileName);
FileStream sourceFile = new FileStream(sFileName,
FileMode.Open);
long FileSize;
FileSize = sourceFile.Length;
byte[] getContent = new byte[(int)FileSize];
sourceFile.Read(getContent, 0, (int)sourceFile.Length);
sourceFile.Close();
Response.BinaryWrite(getContent);
Response.Flush();
bRetValue = true;
// Response.End();
}
catch
{
bRetValue = false;
}
return bRetValue;
}
Thanks,
-j
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] .NET Remoting and Hashtable
Hi,
we work on a project of distributed system where we use the technology
dotNET Remoting. But we have there a small issue.
We have two types of nodes there, managers and storages. They both use the
same method (the method is in dll file - manager and storage have the same
copy of this file).
The method is:
public void UpdateLastSeen(Node n)
{
if (lastSeen.ContainsKey(n))
lastSeen[n] = DateTime.Now;
else
lastSeen.Add(n, DateTime.Now);
}
// Node n - is our own object
// lastSeen is hashtable (key is our own object Node, value is DateTime)
Problem:
The both nodes - managers and also storage peridiocally call this method,
while one of them works well, another one does somethig different with the
same code.
For example the topology is point-to-point, one manager, one storage.
Storage updates active status of the manager well, but manager can't
recognize that it has is connected stil the same node - the same storage.
The result is that the manager does not overwrite the time of last seen of
the node storage, but by timer click it adds allways a new entry into the
hashtable. With the same code storage works great.
No idea where the problem could be, maybe the copy of the object Node is not
the same like in the object stored in the hashtable??
Hope that someone will understand what we tried to explain;) and help.
Thanks a lot
Regards,
michal kohut
--
View this message in context:
http://www.nabble.com/.NET-Remoting-and-Hashtable-tp16324136p16324136.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET Remoting and Hashtable
Hi, nemesis35 wrote: No idea where the problem could be, maybe the copy of the object Node is not the same like in the object stored in the hashtable?? It is definitely not the same object, so you have to implement Node.GetHashCode() to establish a consistent identity that does not rely upon Object.GetHashCode. Note that if Node is a MarshalByRefObject, GetHashCode won't be called remotely. This means that overriding GetHashCode has no effect in other app domains than the creator domain. Robert ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET Remoting and Hashtable
Hi!
Does your Hashtable sit in a MarshalByRef class or a [Serializable] one?
If the latter is the case then each connecting node works on its
separate copy.
Are you positive yor class is marshaled as a singleton rather than
single-call?
Other than that, only putting: lastSeen[n] = DateTime.Now; in the
method body will be a faster solution.
You should also consider using lock(lastSeen) if more than one client
can be connected at a time.
Cheers!
Michał Ziemski
nemesis35 pisze:
Hi,
we work on a project of distributed system where we use the technology
dotNET Remoting. But we have there a small issue.
We have two types of nodes there, managers and storages. They both use the
same method (the method is in dll file - manager and storage have the same
copy of this file).
The method is:
public void UpdateLastSeen(Node n)
{
if (lastSeen.ContainsKey(n))
lastSeen[n] = DateTime.Now;
else
lastSeen.Add(n, DateTime.Now);
}
// Node n - is our own object
// lastSeen is hashtable (key is our own object Node, value is DateTime)
Problem:
The both nodes - managers and also storage peridiocally call this method,
while one of them works well, another one does somethig different with the
same code.
For example the topology is point-to-point, one manager, one storage.
Storage updates active status of the manager well, but manager can't
recognize that it has is connected stil the same node - the same storage.
The result is that the manager does not overwrite the time of last seen of
the node storage, but by timer click it adds allways a new entry into the
hashtable. With the same code storage works great.
No idea where the problem could be, maybe the copy of the object Node is not
the same like in the object stored in the hashtable??
Hope that someone will understand what we tried to explain;) and help.
Thanks a lot
Regards,
michal kohut
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] .net reference license
From scott guthrie's blogpost on wednesday: Reference License The .NET Framework source is being released under a read-only reference license. When we announced that we were releasing the source back in October, some people had concerns about the potential impact of their viewing the source. To help clarify and address these concerns, we made a small change to the license to specifically call out that the license does not apply to users developing software for a non-Windows platform that has the same or substantially the same features or functionality as the .NET Framework. If the software you are developing is for Windows platforms, you can look at the code, even if that software has the same or substantially the same features or functionality as the .NET Framework. I guess this settles the reference license questions, no reading sources for mono developers. As was already suggested by Miquel and others. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] NET S3 client
Hey, Is there an established place for third party Mono libs? I remember there once was a debate about that, but AFAIR it never came to a conclusion (but maybe I missed something). Our recommendation is that new libraries are hosted independently; They can be hosted in our SVN repository, or in code.google.com. The main advantage of our server is that others can update/modify it at will. We used to bundle libraries with Mono, but due to Mono's own release schedule, its API guarantees (see Application Deployment Guidelines in the web site) it is very cumbersome for the developer and for ourselves so we tend to recommend this distributed approach. Once the library is ready to ship (tarball, distcheck) we would certainly like to create ready-to-install packages and distribute those as part of Mono (see OpenSUSE build service). Miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] NET S3 client
Hi! I have written a Amazon S3 client for NET and would like to release it for use to the community. It is IMHO better then the Amazon one as it handles Streams not byte arrays, foolows Net naming conventions and is generally cleaner code. Is there an established place for third party Mono libs? I remember there once was a debate about that, but AFAIR it never came to a conclusion (but maybe I missed something). Will you (the mono team) be interested in that as a new lib in the mono bundle (like Mono.S3 for example). I will be happy to hear from you, what's the best way to go. Best regards, Michał Ziemski ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] .Net Thread Pool
Hi, How can I use .Net thread pool in Mono. If I try to add the following in machine.config of mono on Linux server it starts giving error in Web Application. processModel maxIoThreads=20 maxWorkerThreads=20 / Please let me know if Mono uses .Net Thread pool. Thanks Regards, Simmi Kapoor - Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net Thread Pool
Hi! You can simply use System.Threading.ThreadPool static class. No need to tweak config files at all. Cheers! Michał Ziemski Simmi Kapoor pisze: Hi, How can I use .Net thread pool in Mono. If I try to add the following in machine.config of mono on Linux server it starts giving error in Web Application. processModel maxIoThreads=20 maxWorkerThreads=20 / Please let me know if Mono uses .Net Thread pool. Thanks Regards, Simmi Kapoor Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now http://us.rd.yahoo.com/evt=48223/*http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow (it's updated for today's economy) at Yahoo! Games. ___ 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
[Mono-list] .NET 2.0 WebService XML serialization format
Hello, I have observed that, when writing a WebService using .NET 2.0, if a [WebMethod] returns an object instead of a primitive type, the XmlFormatter is used for serializing it. But, how can I configure the webservice to use the SoapFormatter instead? Regards, Andrés [ knocte ] -- ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] NET Rocks! interview to Miguel de Icaza
Ruben Guinez escribió: Hi Miguel and all folks Thanks to Joe Audette i knew about this: I can to hear you to talk about mono, moonlight and lot of stuff in interview. So Good !!!, And all nice, but I want to know (because my english is better writing than spoken) if it could be possible that you can to talk the same things but in spanish to we can to understand every thing in detail that you say on it?. I know that you have not a few idle time, and if that is not possible don't worry about that. Thanks in advance. (I am studying so hard to learn spoken english) English version: Well, I guess it's a lot to have a full transcription... but who knows. Anyway, if you want to ask ask something on the interview I'll be glad to answer you in Spanish. I leave tomorrow on vacation so... be fast! ;). Cheers! Spanish version: Supongo que será demasiado esfuerzo hacer una transcripción completa de la entrevista, pero quién sabe, quizá alguien lo haga. De todas formas si te interesa saber algo en concreto de lo dicho en la entrevista no me importa responderte en español sobre lo hablado. Me marcho mañana de viaje por lo que me conectaré bastante menos, así que ¡sé rápido! ;). ¡Hasta luego! ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] .NET Remoting
Hi guys,
I'm developing a distributed application in C#, where I want to use .NET
Remoting, but there's problem with it.
Everything works fine when I call remote procedure with parameters of
standard types, like string, int, bool,... But if I want to send an own
object, I get the error: Unhandled Exception:
System.NullReferenceException: Object
reference not set to an instance of an object I tried to use an HttpChannel
and also TcpChannel but the
problem is somewhere else.
I found an example that works when I use dll-s.
THIS IS SERVER:
Main.cs
HttpServerChannel httpchannel = new HttpServerChannel(8085);
ChannelServices.RegisterChannel(httpchannel);
RemotingConfiguration.RegisterWellKnownServiceType(typeof(nsCRemoteObj.CRemoteObj),
CRemoteObjURI,
WellKnownObjectMode.SingleCall
);
///
THIS IS CLIENT:
Main.cs
ChannelServices.RegisterChannel( new HttpChannel() );
IRemoteObj obj = (IRemoteObj) Activator.GetObject(
typeof(IRemoteObj),
http://localhost:8085/CRemoteObjURI;
);
//calling remote procedure
Node node = new Node(127.0.0.1,12345);
Node nout = obj.TestMethod(node);
Console.WriteLine(TestMethod completed. Returned ip: {0}, nout.ipAdd);
/
MY REMOTE CLASS:
CRemoteObj.cs
public class CRemoteObj : System.MarshalByRefObject, IRemoteObj
{
public CRemoteObj()
{
Console.WriteLine(CRemoteObj constructor invoked.);
}
~CRemoteObj()
{
Console.WriteLine(CRemoteObj destructor invoked.);
}
// definition of our method(s)
public Node TestMethod(Node node)
{
Console.WriteLine(CRemoteObj.TestMethod invoked.);
Console.WriteLine(Ip Address = {0}, Port = {1},
node.ipAdd, node.po);
Node nout = node;
nout.ipAdd = manager;
return nout;
}
}
/
AND INTERFACE (includes my own object):
IRemoteObj.cs
// custom object which we want to pass
[Serializable]
public class Node
{
public string ipAdd;
public int po;
public Node()
{
}
public Node(string ipAddress, int port)
{
ipAdd = ipAddress;
po = port;
}
};
// interface which contains declaration of our method(s)
public interface IRemoteObj
{
Node TestMethod(Node node);
}
/
That should work. But it doesn't, only when I make DLL files from Remote
Class (CRemoteObj.cs) and Interface (IRemoteObj.cs). And then I must include
these DLL files into my server and client.
I believe that this can work without DLL but I don't how, so if anyone has
any idea, please help me. I will really appreciate it, I cannot go forward
because of this. I don't want to use DLL files.
Thanx for any help.
--
View this message in context:
http://www.nabble.com/.NET-Remoting-tf3872082.html#a10970553
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET Remoting
Ysgrifennodd nemesis35: Hi guys, I'm developing a distributed application in C#, where I want to use .NET Remoting, but there's problem with it. Does this help? http://www.peredur.uklinux.net/Remoting.pdf If I understand your problem correctly, it has to do with the fact that both the client and server have to have a definition of the type you are trying to pass. I've not read your post in great detail, though, so I could be wrong. Peter ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET Remoting
nemesis35 wrote: / That should work. But it doesn't, only when I make DLL files from Remote Class (CRemoteObj.cs) and Interface (IRemoteObj.cs). And then I must include these DLL files into my server and client. I believe that this can work without DLL but I don't how, so if anyone has any idea, please help me. I will really appreciate it, I cannot go forward because of this. I don't want to use DLL files. The short answer is: it cannot work w/out a shared dll, because when the interfaces are compiled in both assemblies, their identities are not the same anymore. The interfaces will be treated as 2 distinct incompatible types. If you don't like this, you have to drop the interfaces at all and use stubs generated by the soapsuds tool (delivered with mono and MS.NET). It's not worthwhile. Robert ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .net remoting problem with object sending
The problem is that the receiver application can't deserialize the object because it can't find the assembly that implements it. In any case, remoting should not crash with a null ref exception. I just fixed it. Lluis. El dc 28 de 02 del 2007 a les 04:40 +0100, en/na Mirek Binas va escriure: hello i am trying to develop application with .net remoting for communication. at the moment - everything is well, but when i want to send object, that is not one of the default types, the exception raised: Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object the object is not null (checked line before call of the remote method). and in the declaration of the class it is marked as [Serializable]. don't know, what is the problem about. any idea? mirek p.s.: the complete exception Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object Server stack trace: at System.Runtime.Remoting.Channels.SimpleBinder.BindToType (System.String assemblyName, System.String typeName) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapTypeMapper.GetType (System.String xmlName, System.String xmlNamespace) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapReader.Deserialize () [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapReader.Deserialize (System.IO.Stream inStream, ISoapMessage soapMessage) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize (System.IO.Stream serializationStream) [0x0] at System.Runtime.Remoting.Channels.SoapServerFormatterSink.ProcessMessage (IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, System.IO.Stream requestStream, IMessage responseMsg, ITransportHeaders responseHeaders, System.IO.Stream responseStream) [0x0] Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception exc, System.Object[] out_args) [0x0] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] .net remoting problem with object sending
hello i am trying to develop application with .net remoting for communication. at the moment - everything is well, but when i want to send object, that is not one of the default types, the exception raised: Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object the object is not null (checked line before call of the remote method). and in the declaration of the class it is marked as [Serializable]. don't know, what is the problem about. any idea? mirek p.s.: the complete exception Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object Server stack trace: at System.Runtime.Remoting.Channels.SimpleBinder.BindToType (System.String assemblyName, System.String typeName) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapTypeMapper.GetType (System.String xmlName, System.String xmlNamespace) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapReader.Deserialize () [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapReader.Deserialize (System.IO.Stream inStream, ISoapMessage soapMessage) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize (System.IO.Stream serializationStream) [0x0] at System.Runtime.Remoting.Channels.SoapServerFormatterSink.ProcessMessage (IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, System.IO.Stream requestStream, IMessage responseMsg, ITransportHeaders responseHeaders, System.IO.Stream responseStream) [0x0] Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception exc, System.Object[] out_args) [0x0] -- e-mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] homepage: http://www.intrak.sk/~binas english: Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc a .ppt (power point) precitajte si http://www.fsf.org/philosophy/no-word-attachments.cs.html ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .net remoting problem with object sending
Hi there, I am a little guessing here but it sounds as if you would using XML/SOAP/WEB kind of remoting. In this case make sure each and every variable in your object/class/struct is defined and initialized. You can also switch to a binary formater which will solve this issue too but will break access through proxy. Regards, Axel Am 28.02.2007 4:40 Uhr schrieb Mirek Binas unter [EMAIL PROTECTED]: hello i am trying to develop application with .net remoting for communication. at the moment - everything is well, but when i want to send object, that is not one of the default types, the exception raised: Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object the object is not null (checked line before call of the remote method). and in the declaration of the class it is marked as [Serializable]. don't know, what is the problem about. any idea? mirek p.s.: the complete exception Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object Server stack trace: at System.Runtime.Remoting.Channels.SimpleBinder.BindToType (System.String assemblyName, System.String typeName) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapTypeMapper.GetType (System.String xmlName, System.String xmlNamespace) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapReader.Deserialize () [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapReader.Deserialize (System.IO.Stream inStream, ISoapMessage soapMessage) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x0] at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize (System.IO.Stream serializationStream) [0x0] at System.Runtime.Remoting.Channels.SoapServerFormatterSink.ProcessMessage (IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, System.IO.Stream requestStream, IMessage responseMsg, ITransportHeaders responseHeaders, System.IO.Stream responseStream) [0x0] Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception exc, System.Object[] out_args) [0x0] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .net remoting problem with object sending
Hi there,
Don't get me wrong. You can use a binary formater AND an HTTP channel.
Like this
Server
HttpChannel hc;
BinaryServerFormatterSinkProvider sbf = new
BinaryServerFormatterSinkProvider();
BinaryClientFormatterSinkProvider cbf = new
BinaryClientFormatterSinkProvider();
IDictionary properties = new Hashtable();
properties[port] = port;
if( !fqdn.Equals() ){
properties[machineName] = fqdn;
}
else{
Helper.ErrorLog(ManageMail DB Provider using IP as no fqdn found);
}
hc=new HttpChannel(properties,cbf,sbf);
ChannelServices.RegisterChannel(hc,false);
RemotingConfiguration.ApplicationName=DBAbstract;
RemotingConfiguration.RegisterActivatedServiceType(typeof(DBAbstract));
Client
try{
BinaryServerFormatterSinkProvider sbf = new
BinaryServerFormatterSinkProvider();
BinaryClientFormatterSinkProvider cbf = new
BinaryClientFormatterSinkProvider();
IDictionary properties = new Hashtable();
properties[name] = ManageMail LogViewer;
ChannelServices.RegisterChannel(new HttpChannel(properties,cbf,sbf),false);
RemotingConfiguration.RegisterActivatedClientType(typeof(DBAbstract),dbInfo.
GetRemotingString());
}
catch{
Application.Exit();
return;
}
Regards,
Axel
Am 28.02.2007 7:52 Uhr schrieb Mirek Binas unter
[EMAIL PROTECTED]:
hello
yes - i am using the http channel for remoting. the problematic object
consists of four attributes, and all of them are initialized. hmm... i'll try
to play a bit, if this is the problem.
and - i was trying to use tcp channel for this purpose, but at the very first
begging with problems, so because of this i switched to http. but - i'll try
it again, if this should be the problem.
mirek
On Wed, Feb 28, 2007 at 07:40:03AM +0100, Axel Westerhold wrote:
Hi there,
I am a little guessing here but it sounds as if you would using XML/SOAP/WEB
kind of remoting. In this case make sure each and every variable in your
object/class/struct is defined and initialized.
You can also switch to a binary formater which will solve this issue too but
will break access through proxy.
Regards,
Axel
Am 28.02.2007 4:40 Uhr schrieb Mirek Binas unter
[EMAIL PROTECTED]:
hello
i am trying to develop application with .net remoting for communication. at
the moment - everything is well, but when i want to send object, that is not
one of the default types, the exception raised:
Unhandled Exception: System.NullReferenceException: Object reference not set
to an instance of an object
the object is not null (checked line before call of the remote method). and
in
the declaration of the class it is marked as [Serializable]. don't know,
what
is the problem about. any idea?
mirek
p.s.: the complete exception
Unhandled Exception: System.NullReferenceException: Object reference not set
to an instance of an object
Server stack trace:
at System.Runtime.Remoting.Channels.SimpleBinder.BindToType (System.String
assemblyName, System.String typeName) [0x0]
at System.Runtime.Serialization.Formatters.Soap.SoapTypeMapper.GetType
(System.String xmlName, System.String xmlNamespace) [0x0]
at System.Runtime.Serialization.Formatters.Soap.SoapReader.Deserialize ()
[0x0]
at System.Runtime.Serialization.Formatters.Soap.SoapReader.Deserialize
(System.IO.Stream inStream, ISoapMessage soapMessage) [0x0]
at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize
(System.IO.Stream serializationStream,
System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x0]
at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize
(System.IO.Stream serializationStream) [0x0]
at System.Runtime.Remoting.Channels.SoapServerFormatterSink.ProcessMessage
(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, System.IO.Stream requestStream, IMessage responseMsg,
ITransportHeaders responseHeaders, System.IO.Stream responseStream)
[0x0]
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke
(System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg,
System.Exception
exc, System.Object[] out_args) [0x0]
___
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] .net remoting problem with object sending
One more comment,
I used XML formating but hit a brickwall because while all my entities were
properly defiend and initialized some Framework components were not. As soon
as the XML Formater found a Null within a collection, object or class it
stopped working. Since I use the binary formater my problems are gone and it
seems to work very stable (loading 100.000,00 records in one run and loading
new records in 5 sec. Intervals für 12 hours. It behaves well in my threaded
eviroment and while the server runs on Linux the client is on windows.
Axel
Am 28.02.2007 8:08 Uhr schrieb Axel Westerhold unter
[EMAIL PROTECTED]:
Hi there,
Don't get me wrong. You can use a binary formater AND an HTTP channel.
Like this
Server
HttpChannel hc;
BinaryServerFormatterSinkProvider sbf = new
BinaryServerFormatterSinkProvider();
BinaryClientFormatterSinkProvider cbf = new
BinaryClientFormatterSinkProvider();
IDictionary properties = new Hashtable();
properties[port] = port;
if( !fqdn.Equals() ){
properties[machineName] = fqdn;
}
else{
Helper.ErrorLog(ManageMail DB Provider using IP as no fqdn found);
}
hc=new HttpChannel(properties,cbf,sbf);
ChannelServices.RegisterChannel(hc,false);
RemotingConfiguration.ApplicationName=DBAbstract;
RemotingConfiguration.RegisterActivatedServiceType(typeof(DBAbstract));
Client
try{
BinaryServerFormatterSinkProvider sbf = new
BinaryServerFormatterSinkProvider();
BinaryClientFormatterSinkProvider cbf = new
BinaryClientFormatterSinkProvider();
IDictionary properties = new Hashtable();
properties[name] = ManageMail LogViewer;
ChannelServices.RegisterChannel(new HttpChannel(properties,cbf,sbf),false);
RemotingConfiguration.RegisterActivatedClientType(typeof(DBAbstract),dbInfo.
GetRemotingString());
}
catch{
Application.Exit();
return;
}
Regards,
Axel
Am 28.02.2007 7:52 Uhr schrieb Mirek Binas unter
[EMAIL PROTECTED]:
hello
yes - i am using the http channel for remoting. the problematic object
consists of four attributes, and all of them are initialized. hmm... i'll try
to play a bit, if this is the problem.
and - i was trying to use tcp channel for this purpose, but at the very first
begging with problems, so because of this i switched to http. but - i'll try
it again, if this should be the problem.
mirek
On Wed, Feb 28, 2007 at 07:40:03AM +0100, Axel Westerhold wrote:
Hi there,
I am a little guessing here but it sounds as if you would using XML/SOAP/WEB
kind of remoting. In this case make sure each and every variable in your
object/class/struct is defined and initialized.
You can also switch to a binary formater which will solve this issue too but
will break access through proxy.
Regards,
Axel
Am 28.02.2007 4:40 Uhr schrieb Mirek Binas unter
[EMAIL PROTECTED]:
hello
i am trying to develop application with .net remoting for communication. at
the moment - everything is well, but when i want to send object, that is
not
one of the default types, the exception raised:
Unhandled Exception: System.NullReferenceException: Object reference not
set
to an instance of an object
the object is not null (checked line before call of the remote method). and
in
the declaration of the class it is marked as [Serializable]. don't know,
what
is the problem about. any idea?
mirek
p.s.: the complete exception
Unhandled Exception: System.NullReferenceException: Object reference not
set
to an instance of an object
Server stack trace:
at System.Runtime.Remoting.Channels.SimpleBinder.BindToType
(System.String
assemblyName, System.String typeName) [0x0]
at System.Runtime.Serialization.Formatters.Soap.SoapTypeMapper.GetType
(System.String xmlName, System.String xmlNamespace) [0x0]
at System.Runtime.Serialization.Formatters.Soap.SoapReader.Deserialize ()
[0x0]
at System.Runtime.Serialization.Formatters.Soap.SoapReader.Deserialize
(System.IO.Stream inStream, ISoapMessage soapMessage) [0x0]
at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize
(System.IO.Stream serializationStream,
System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x0]
at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize
(System.IO.Stream serializationStream) [0x0]
at
System.Runtime.Remoting.Channels.SoapServerFormatterSink.ProcessMessage
(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, System.IO.Stream requestStream, IMessage responseMsg,
ITransportHeaders responseHeaders, System.IO.Stream responseStream)
[0x0]
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke
(System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg,
System.Exception
exc, System.Object[] out_args) [0x0]
Re: [Mono-list] .NET 3.0 misnomer
Miguel de Icaza-4 wrote: If you need cross platform APIs, then do not use any APIs that are not implemented by Mono. It is that simple. I know. That's besides the point though, because you couldn't possibly tell that to Microsoft. Or, that would no doubt be the perception to say the least. You work with people who know Mono inside out. But believe me, it really isn't good for Mono for there to be more unimplemented .NET components. It just makes both .NET and Mono look flimsy, and certainly as that becomes the case, Microsoft's devs will become more and more careless as well. As with any other open source project, if you need something that is not implemented by it, and you absolutely must have it, you can always implement it. Either yourself, or a third party, but you can implement it. My suggestion is to stay on the safe side and use Mono implemented APIs, and even the Mono stack. I know, although I don't think anyone has the resources or energy to implement anything more than a quick hack most of the time. In any case, thanks for taking the time to chat. I'm still not convinced that the name switch is a good move, and it doesn't seem like you disagree with me on that, seeing that you seem to agree with me for the most part, intentionally or not. By the way, if you don't mind me breaking the mailing list etiquette a little (I bet it's there for this exact reason), great work on Mono. I love watching it grow and become more and more useful. -- View this message in context: http://www.nabble.com/%22.NET-3.0%22-misnomer-tf2092941.html#a5793561 Sent from the Mono - General forum at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET 3.0 misnomer
Hi Miguel, If you need cross platform APIs, then do not use any APIs that are not implemented by Mono. It is that simple. As with any other open source project, if you need something that is not implemented by it, and you absolutely must have it, you can always implement it. Either yourself, or a third party, but you can implement it. My suggestion is to stay on the safe side and use Mono implemented APIs, and even the Mono stack. Picking this out of its context, you are forgetting one thing: APIs usually evolve around two principles - add features and simplify tasks. The latter is the reason why I am not sticking with .NET 1.1 and waiting for .NET 2.0 support to be declared complete - C# generics make writing some of my libraries dramatically faster, and that boost in productivity was one of the reasons I started using .NET instead of C++/COM in the first place. Now I don't need the neat Avalon graphics stuff and especially not XML based UIs but I did hear rumors WPF would provide support for navigational apps - whereas currently I need to write and maintain my own Inductive UI framework based on System.Windows.Forms. Restricting yourself to a common set of APIs is a pain really; I wanted WS-BaseNotification so in addition to the required SOAP message exchanges I had to write my own TCP based and WS-Addressing compatible SOAP stack, functionality provided on Windows by Microsoft's WSE and probably Indigo/WCF but to my knowledge not on Mono. So such a decision for cross-platform software does not always come easy or without a price to pay. Having more ready-to-use cross-platform libraries that fit such niches would help to that aspect (e.g. few really need a clone of an everchanging WSE but people might need some of the features independent of the API). Might it be possible to host something like http://www.apple.com/downloads/macosx/ to assist developers in finding existing cross-platform or Mono-specific libraries? For example, have a category Graphics or Charts and list ZedGraph and NPlot there and make it easily locatable on the site - as a marketing effect this would show to people new to Mono that there are in fact lots of compatible libraries around, and for the existing developers it could avoid some lengthy googling for specific things. Mentioning that we could/should add missing features ourselves, I might try that for System.IO.UnmanagedMemoryStream (which appeared to be missing in 1.1.16?), writing a new C# class is pretty straightforward and does not require knowledge of previous code, but messing around with the runtime definitely is not as easy. Nontheless, it's still unparalleled cool that I can seemlessly run .NET based apps on Windows, Linux, Mac OS X and Solaris at all! I didn't imagine this when I started .NET coding in 2002. Best regards, Andreas ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET 3.0 misnomer
Hello, Having more ready-to-use cross-platform libraries that fit such niches would help to that aspect (e.g. few really need a clone of an everchanging WSE but people might need some of the features independent of the API). Might it be possible to host something like http://www.apple.com/downloads/macosx/ to assist developers in finding existing cross-platform or Mono-specific libraries? For example, have a category Graphics or Charts and list ZedGraph and NPlot there and make it easily locatable on the site - as a marketing effect this would show to people new to Mono that there are in fact lots of compatible libraries around, and for the existing developers it could avoid some lengthy googling for specific things. The idea is good, if we can find someone to maintain the directory, I would be happy to hand out accounts to the web site. Mentioning that we could/should add missing features ourselves, I might try that for System.IO.UnmanagedMemoryStream (which appeared to be missing in 1.1.16?), writing a new C# class is pretty straightforward and does not require knowledge of previous code, but messing around with the runtime definitely is not as easy. Someone contributed a patch for it, which is on my queue for review. Miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] .NET weather API/Control
Hi guys, Does anyone knows a .NET API or control for winforms, to retrieve the weather from accuweather or weather.com ? Something like the forecastfox for firefox (hope i'm talking right). I'm searching and searching... and nothing. Jorge ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET 3.0 misnomer
Hello, Not that minor details like this have stopped us from implementing the parts that *are* interesting (jchamber's COM interop work, P/Invoke), even if they're not portable (lupus quote: P/Invoke is poorly defined in a non-win32 system.). There is a lot more depth in the P/Invoke situation though. P/Invoke has limitations, not only on Unix, but also on Windows. And the lack of specifications is just the result of the balance between shipping something or keeping it on the drawing board forever. The good news is that there are folks in the .NET group that are willing to address some of our concerns (some were handled by the previous pass at ECMA, but its limited by the product that is currently shipping). Miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET 3.0 misnomer
Hello, Now the problem is this: if nearly all of .NET 2.0 is portable, and none of NET 3.0 is portable, and .NET 3.5 will have crucial changes like LinQ, there's no guarantee that .NET 3.5 onward won't depend on .NET 3.0, therefore making .NET unportable. I have not seen anything in .NET 3.0 which is inherently difficult to implement on Unix. If you could point out something that you think is fundamentally unimplementable, we could have a discussion about that feature. Miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET 3.0 misnomer
Miguel de Icaza-4 wrote: If you could point out something that you think is fundamentally unimplementable, we could have a discussion about that feature. I'm guessing certain aspects are already easier to implement than WinForms (due to things like the dispatcher replacing the message pump), but really, no one expects Mono to be able to manage it. Most of us are more worried about whether Mono would actually take on the task than we are about whether or not it can be done. Effectively Mono would be stuck at 2.0 while .NET is at 3.0, and 3.5 onward would be incomplete (like I wrote in the petition, the 3 would be missing). Even if that's not the truth about 3.5+, it will be the perception, and it will hurt Mono, which in turn will hurt .NET. So my question is this: will you do .NET 3.0? Thanks, Rei -- View this message in context: http://www.nabble.com/%22.NET-3.0%22-misnomer-tf2092941.html#a5789102 Sent from the Mono - General forum at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET 3.0 misnomer
On Fri, 2006-08-11 at 14:05 -0700, reinux wrote: Now the problem is this: if nearly all of .NET 2.0 is portable, ...which is incorrect... It is portable enough to be functional - without COM, without WinForms, without EnterpriseServices. You're missing the point here - if any crucial changes are made in 3.5 that rely on 3.0, all subsequent versions will no longer be portable. Also, you've trimmed out a crucial point in my message: the _whole_ of .NET 3.0 is incompatible. To be insanely literal, everything outside of ECMA isn't necessarily portable, and ECMA doesn't contain much (~250 classes, IIRC). That is insanely literal. You'd expect the Mono project to be abandoned if everyone worried about that. LINQ is supposed to be a very generic framework. Generic enough to work for arbitrary object graphs (IEnumerable), System.Xml, and System.Data. I would like to see how they could make LINQ depend on something as specific as Avalon Indigo, while still permitting it to be generic enough to work with what they've said it would work with. (I seriously doubt that it could be done in any rational manner.) LINQ may be safe. However, just having an anomaly in there of such size raises the risk and the _perception_ of risk enough to scare people away from the framework altogether. Sure, WinForms and such aren't portable, but are those areas on which newer technologies will be built, as will undeniably be the case with WCF and WPF? This doesn't mean that other features couldn't be introduced that depend on the newer WinFX libraries, but even if WinFX isn't termed .NET 3.0, does that really change anything? Really? If they _don't_ call it .NET 3.0, they'd instead require that your future applications depend on both .NET 3.0 w/o WinFX + WinFX -- i.e. you'd need two dependencies instead of just one. And nothing stops them from making .NET 3.0 w/o WinFX from depending on WinFX (as a circular dependency). If you've seen Vista's development with trying to build a huge chunk of the OS on a non-existent API, you'd see that circular dependencies while they may sometimes be tried, they will be less likely. Think WinFS and its setbacks before it was abandoned. The reason isn't technical but it's still simple enough: development schedules and team structures. We aren't talking about just software here - we're also talking about business. And yes, most of Microsoft's future software will probably require both WinFX and .NET. However, that is much better than risking everything requiring both as well. It'd be ridiculous for people to need to say Requires .NET 2.0 Framework but not .NET 3.0 or Requires .NET 3.5 Framework but not .NET 3.0. There are _far_ better things to spend your energy on. The naming of WinFX is quite inconsequential, and was done primarily to keep the dependencies sane for ISVs (only one dependency to install, not two) and marketing purposes (to kill the WinFX is going to replace .NET! insanity from those who really don't know any better). Of course. Technically it has no effect for now. I spent all this energy knowing that it all boils down to marketing, and better marketing is what I'm arguing for. It's not entirely technical; perceptions can change on the part of Mono devs and users, and worse, they can also change within Microsoft itself. Then it'll really become technical. Thanks for the feedback, Rei -- View this message in context: http://www.nabble.com/%22.NET-3.0%22-misnomer-tf2092941.html#a5789173 Sent from the Mono - General forum at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET 3.0 misnomer
hello, If you could point out something that you think is fundamentally unimplementable, we could have a discussion about that feature. I'm guessing certain aspects are already easier to implement than WinForms (due to things like the dispatcher replacing the message pump), but really, no one expects Mono to be able to manage it. Most of us are more worried about whether Mono would actually take on the task than we are about whether or not it can be done. That is a valid concern, but that has nothing to do with the portability of 3.0; It seems actually that all of 3.0 is more Unix friendly than Windows.Forms was. Effectively Mono would be stuck at 2.0 while .NET is at 3.0, and 3.5 onward would be incomplete (like I wrote in the petition, the 3 would be missing). Even if that's not the truth about 3.5+, it will be the perception, and it will hurt Mono, which in turn will hurt .NET. Well, am not too concerned about the label; Today Mono is not even a complete 1.1 implementation, it misses pieces like EnterpriseServices and it is still very useful to people. In the same spirit, we might implement C# 3.0 without implementing the rest of the .NET 3.0 stack, but that does not mean it is not useful. It just means that there is no parity in version numbers (but even today, there is no parity in version numbers). So my question is this: will you do .NET 3.0? It is too early to tell. From a personal standpoint, there are things I like, things I do not like in 3.0, and am not sure how excited am about implementing those ones. From a Novell point of view, if we find that implementing these might be of strategic value for our Linux business (buy SUSE :-), we might look at implementing those. From a community standpoint, it might very well happen that some of those pieces are implemented by third-parties; And the code could be merged, or not with Mono. From a project point point of view, tracking a moving API is difficult and it would be best to invest our time on the APIs that are set in stone instead of the shifting ones that 3.0 are at this point. It is too early to start getting alarmed at the falling sky. I think that 3.0 stuff should be kept on a separate package, if only because it would be a release nightmare otherwise (and I already would like to split up some of the stuff in mcs/class into other packages, but we haven't done merely because of logistical and resource requirements). Miguel. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET 3.0 misnomer
Hello, It is portable enough to be functional - without COM, without WinForms, without EnterpriseServices. You're missing the point here - if any crucial changes are made in 3.5 that rely on 3.0, all subsequent versions will no longer be portable. Also, you've trimmed out a crucial point in my message: the _whole_ of .NET 3.0 is incompatible. Do you have any specifics --leaving all punditry aside, please-- or are you just pre-emptively freaking out? Of course. Technically it has no effect for now. I spent all this energy knowing that it all boils down to marketing, and better marketing is what I'm arguing for. It's not entirely technical; perceptions can change on the part of Mono devs and users, and worse, they can also change within Microsoft itself. Then it'll really become technical. I think I will start using colors to represent technologies, a play on words on mono, monochrome, so we could have cyan, magenta, blue, yellow. My main concern at this point is whether to choose additive or subtractive colors for the naming. Miguel. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET 3.0 misnomer
Miguel de Icaza-4 wrote: It is portable enough to be functional - without COM, without WinForms, without EnterpriseServices. You're missing the point here - if any crucial changes are made in 3.5 that rely on 3.0, all subsequent versions will no longer be portable. Also, you've trimmed out a crucial point in my message: the _whole_ of .NET 3.0 is incompatible. Do you have any specifics --leaving all punditry aside, please-- or are you just pre-emptively freaking out? You've answered it's too early to say to the question of whether or not you will be implementing WinFX on Mono. Unless the answer to that is yes, it doesn't matter whether or not there's any specifics. Why would there be specifics when the whole thing is a big maybe? There's two components to the problem: the perception and the risk (after all, that's what a name is about). You wouldn't run around with a pair of scissors in your hand just because you haven't tripped yet, would you? .NET isn't stopping at 3.5. Miguel de Icaza-4 wrote: Of course. Technically it has no effect for now. I spent all this energy knowing that it all boils down to marketing, and better marketing is what I'm arguing for. It's not entirely technical; perceptions can change on the part of Mono devs and users, and worse, they can also change within Microsoft itself. Then it'll really become technical. I think I will start using colors to represent technologies, a play on words on mono, monochrome, so we could have cyan, magenta, blue, yellow. My main concern at this point is whether to choose additive or subtractive colors for the naming. I'm not dull enough not to notice that you're trying to make a caricature here but at the same time I don't think I'm sophisticated enough to see your joke. Could you elaborate on what you're trying to insinuate? -- View this message in context: http://www.nabble.com/%22.NET-3.0%22-misnomer-tf2092941.html#a5791513 Sent from the Mono - General forum at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET 3.0 misnomer
Miguel de Icaza-4 wrote: If you could point out something that you think is fundamentally unimplementable, we could have a discussion about that feature. I'm guessing certain aspects are already easier to implement than WinForms (due to things like the dispatcher replacing the message pump), but really, no one expects Mono to be able to manage it. Most of us are more worried about whether Mono would actually take on the task than we are about whether or not it can be done. That is a valid concern, but that has nothing to do with the portability of 3.0; It seems actually that all of 3.0 is more Unix friendly than Windows.Forms was. That's what I just said, except in the other order. It's this concern that I'm concerned about. Miguel de Icaza-4 wrote: Well, am not too concerned about the label; Today Mono is not even a complete 1.1 implementation, it misses pieces like EnterpriseServices and it is still very useful to people. I'm not surprised that the naming doesn't concern you much. You're the Mono project lead, of course a little naming oopsie isn't going to affect your immediate work. But if you were a developer or user, you'd be concerned. You'd be worried about whether or not 3.5 onward is going to depend on 3, because if you recall COM (and virtaully all .NET libraries) versioning rules, even if the numbers aren't incremental, they are in order, and the higher includes the lower. And again, yes, Mono is useful even though certain things are missing, but not surprisingly, these components also happen to be ones that I don't use much either, even though I spend most of my time using the original .NET implementation on Windows. That won't be true this time around. Miguel de Icaza-4 wrote: So my question is this: will you do .NET 3.0? It is too early to tell. From a personal standpoint, there are things I like, things I do not like in 3.0, and am not sure how excited am about implementing those ones. From a Novell point of view, if we find that implementing these might be of strategic value for our Linux business (buy SUSE :-), we might look at implementing those. From a community standpoint, it might very well happen that some of those pieces are implemented by third-parties; And the code could be merged, or not with Mono. From a project point point of view, tracking a moving API is difficult and it would be best to invest our time on the APIs that are set in stone instead of the shifting ones that 3.0 are at this point. It is too early to start getting alarmed at the falling sky. I don't feel any better then. From a developer standpoint as well as an end-user standpoint, I don't know whether I'm supposed to expect .NET to have much of a future outside Windows, in part or in whole. Until the answer to whether or not WinFX will be implemented on Mono is a yes, I never will know. Sure the sky isn't falling (yet), but do you think I'm the only one that gets the impression that it might? If things like LinQ aren't reliant on 3.0, then show that in the name for God's sake! If you haven't noticed yet, that's what I'm petitioning for. Miguel de Icaza-4 wrote: I think that 3.0 stuff should be kept on a separate package, if only because it would be a release nightmare otherwise (and I already would like to split up some of the stuff in mcs/class into other packages, but we haven't done merely because of logistical and resource requirements). Exactly, and that's what I'm freaking out about. -- View this message in context: http://www.nabble.com/%22.NET-3.0%22-misnomer-tf2092941.html#a5791514 Sent from the Mono - General forum at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET 3.0 misnomer
Hello, I don't feel any better then. From a developer standpoint as well as an end-user standpoint, I don't know whether I'm supposed to expect .NET to have much of a future outside Windows, in part or in whole. Until the answer to whether or not WinFX will be implemented on Mono is a yes, I never will know. If you need cross platform APIs, then do not use any APIs that are not implemented by Mono. It is that simple. As with any other open source project, if you need something that is not implemented by it, and you absolutely must have it, you can always implement it. Either yourself, or a third party, but you can implement it. My suggestion is to stay on the safe side and use Mono implemented APIs, and even the Mono stack. If things like LinQ aren't reliant on 3.0, then show that in the name for God's sake! If you haven't noticed yet, that's what I'm petitioning for. Linq does not depend on any of the extras in 3.0, it does not depend on Avalon, does not depend on Workflow, does not depend on Infocard and does not depend on Indigo (or whatever names they have this week). Miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] .NET 3.0 misnomer
You probably know about WinFX being renamed to .NET 3.0. .NET 3.0 is being called an additive update, which means no breaking changes, just additional features. Now the problem is this: if nearly all of .NET 2.0 is portable, and none of .NET 3.0 is portable, and .NET 3.5 will have crucial changes like LinQ, there's no guarantee that .NET 3.5 onward won't depend on .NET 3.0, therefore making .NET unportable. It's a little late now, but I think we need to try to persuade them to reverse this short-sighted decision. Knowing how often they change product names, we still have a chance. http://www.petitiononline.com/winfx/petition.html -- View this message in context: http://www.nabble.com/%22.NET-3.0%22-misnomer-tf2092941.html#a5769506 Sent from the Mono - General forum at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET 3.0 misnomer
On Fri, 2006-08-11 at 14:05 -0700, reinux wrote: Now the problem is this: if nearly all of .NET 2.0 is portable, ...which is incorrect... Seriously, there are large parts of .NET *1.1* which aren't portable. System.EnterpriseServices.dll, anyone? Hell, System.Windows.Forms isn't exactly portable. Not that this is stopping us, but it was never intended to be a cross-platform toolkit. Then there's System.Management, System.Messaging, COM interop... To be insanely literal, everything outside of ECMA isn't necessarily portable, and ECMA doesn't contain much (~250 classes, IIRC). Not that minor details like this have stopped us from implementing the parts that *are* interesting (jchamber's COM interop work, P/Invoke), even if they're not portable (lupus quote: P/Invoke is poorly defined in a non-win32 system.). and none of .NET 3.0 is portable, and .NET 3.5 will have crucial changes like LinQ, there's no guarantee that .NET 3.5 onward won't depend on .NET 3.0, therefore making .NET unportable. I wouldn't spend too much energy on this argument. LINQ is supposed to be a very generic framework. Generic enough to work for arbitrary object graphs (IEnumerable), System.Xml, and System.Data. I would like to see how they could make LINQ depend on something as specific as Avalon Indigo, while still permitting it to be generic enough to work with what they've said it would work with. (I seriously doubt that it could be done in any rational manner.) This doesn't mean that other features couldn't be introduced that depend on the newer WinFX libraries, but even if WinFX isn't termed .NET 3.0, does that really change anything? Really? If they _don't_ call it .NET 3.0, they'd instead require that your future applications depend on both .NET 3.0 w/o WinFX + WinFX -- i.e. you'd need two dependencies instead of just one. And nothing stops them from making .NET 3.0 w/o WinFX from depending on WinFX (as a circular dependency). There are _far_ better things to spend your energy on. The naming of WinFX is quite inconsequential, and was done primarily to keep the dependencies sane for ISVs (only one dependency to install, not two) and marketing purposes (to kill the WinFX is going to replace .NET! insanity from those who really don't know any better). - Jon ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] .NET Hosting Suggestions?
Not sure how off-topic this is for this group, but I'll ask anyway just incase... Can anyone recommend a good (and low-priced, if possible) web host for hosting .NET web applications? I ask because my friend and I have been working on and testing a site as part of a small business endeavor. We're going to host it 100% ourselves eventually, but need to kick-start the income a bit in order to budget a production-class web server and commercial internet connection. So what we need is a host where we can run our .NET website (which, in and of itself, is pretty simple), a database for it to reference where we can, of course, have control over our tables (MySQL would be preferred, but not entirely necessary), and be able to use an outbound SMTP service to go along with .NET's Mail object in the code (a minor concern, but necessary for the site to do its stuff). Ideally, we'd want something more geared towards geeks, where we can keep the whole thing simple and avoid all the marketing speak. I've never actually used 3rd party hosting before, so I honestly don't even know where to look. Of course, Google searches for things like .NET web hosting return about half the internet. And I'd much rather have a first-hand account of someone who's been happy with a particular one, for whatever reasons. Any advice would be much appreciated. Thank you. -David P. Donahue [EMAIL PROTECTED] http://www.cyber0ne.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET Hosting Suggestions?
I recommend www.GrokThis.net Cheers, Joe joe_audette [at] yahoo dotcom http://www.joeaudette.com http://www.mojoportal.com - Original Message From: David P. Donahue [EMAIL PROTECTED] To: mono-list mono-list@lists.ximian.com Sent: Wednesday, May 31, 2006 12:07:45 PM Subject: [Mono-list] .NET Hosting Suggestions? Not sure how off-topic this is for this group, but I'll ask anyway just incase... Can anyone recommend a good (and low-priced, if possible) web host for hosting .NET web applications? I ask because my friend and I have been working on and testing a site as part of a small business endeavor. We're going to host it 100% ourselves eventually, but need to kick-start the income a bit in order to budget a production-class web server and commercial internet connection. So what we need is a host where we can run our .NET website (which, in and of itself, is pretty simple), a database for it to reference where we can, of course, have control over our tables (MySQL would be preferred, but not entirely necessary), and be able to use an outbound SMTP service to go along with .NET's Mail object in the code (a minor concern, but necessary for the site to do its stuff). Ideally, we'd want something more geared towards geeks, where we can keep the whole thing simple and avoid all the marketing speak. I've never actually used 3rd party hosting before, so I honestly don't even know where to look. Of course, Google searches for things like .NET web hosting return about half the internet. And I'd much rather have a first-hand account of someone who's been happy with a particular one, for whatever reasons. Any advice would be much appreciated. Thank you. -David P. Donahue [EMAIL PROTECTED] http://www.cyber0ne.com ___ 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] .NET Hosting Suggestions?
I like DailyRazor. http://www.dailyrazor.com/ Plesk is the admin tool I use to configure my sites. Their service is responsive and usually gets it right the first time. I had just one problem with changing my billing from qtrly to annual. I tried using Click on Hosting. Their service was the worst I have ever experienced. I paid for a full yr with them and left after 2 months. I didnt even bother trying to get a refund. Matt David P. Donahue wrote: Not sure how off-topic this is for this group, but I'll ask anyway just incase... Can anyone recommend a good (and low-priced, if possible) web host for hosting .NET web applications? I ask because my friend and I have been working on and testing a site as part of a small business endeavor. We're going to host it 100% ourselves eventually, but need to kick-start the income a bit in order to budget a production-class web server and commercial internet connection. So what we need is a host where we can run our .NET website (which, in and of itself, is pretty simple), a database for it to reference where we can, of course, have control over our tables (MySQL would be preferred, but not entirely necessary), and be able to use an outbound SMTP service to go along with .NET's Mail object in the code (a minor concern, but necessary for the site to do its stuff). Ideally, we'd want something more geared towards geeks, where we can keep the whole thing simple and avoid all the marketing speak. I've never actually used 3rd party hosting before, so I honestly don't even know where to look. Of course, Google searches for things like .NET web hosting return about half the internet. And I'd much rather have a first-hand account of someone who's been happy with a particular one, for whatever reasons. Any advice would be much appreciated. Thank you. -David P. Donahue [EMAIL PROTECTED] http://www.cyber0ne.com ___ 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
[Mono-list] .NET Technologies 2006 - Call for Participation
CALL FOR PARTICIPATION --- .NET TECHNOLOGIES 2006 4th International Conference on .NET Technologies University of West Bohemia Pilsen (Czech Republic) May 29-June 1, 2006 http://dotnet.zcu.cz --- SCOPE AND OBJECTIVES -- The 4rd International Conference on .NET Technologies aims at bringing together practitioners and researchers from academia and the industry to discuss the latest developments in .NET and advance the state of the art in the research on related technologies. Interest in these topics has been continuously growing as a consequence of the importance and the ubiquity of object-oriented technologies. .NET Technologies 2006 builds upon the positive experience of the previous editions of the event, held in Plzen in February 2003, May 2004 and May 2005. TOPICS --- Original papers describing theoretical and practical results (experience reports and case studies) are solicited in the following areas, but not restricted to: - SOFTWARE ENGINEERING: software components, large-scale software, software correctness, software security, compiling techniques - PROGRAMMING LANGUAGES AND TECHNIQUES: object-oriented techniques, programming paradigms, multi-language programming, compitation techniques - PARALLEL AND DISTRIBUTED COMPUTING: multithreading, distributed applications, high-performance computing, web services, - VIRTUAL MACHINES AND BYTECODE, - ASPECT ORIENTED PROGRAMMING AND DEVELOPMENT, - ALGORITHMS AND DATA STRUCTURES, - EDUCATIONAL ASPECTS: teaching object-oriented paradigm with .NET, educational software, - HUMAN COMPUTER INTERFACES: computer graphics, virtual reality with .NET, - SUPPORT FOR .NET ON UNIX: Mono project, ROTOR, DotGNU, Portable.NET, - APPLICATONS of .NET platform - OTHER TOPICS RELATED TO .NET. SUBMISSION GUIDELINES -- Submitted papers must not have been published or concurrently submitted/considered for publication elsewhere. All submissions will be judged on the basis of originality, contribution to the field, technical and presentation quality, and relevance to the conference. Each paper will be refereed by at least 3 reviewers. Presented papers will be included in the conference proceedings with ISBN. Papers should be written in English and not exceed 8 pages in A4 format. Further information and instructions about submissions can be found on the conference website. PUBLICATION - The best papers presented at the conference will be published in the Journal of .NET Technology ISSN 1801-2108. Full, short communication papers and posters will be published in proceedings with ISBN. IMPORTANT DATES - Abstract submission: February 21, 2006 (recommended) Paper submission: February 28, 2006 Author notification: April 14, 2006 Camera-ready papers due: April 30, 2006 Venue: May 29 - June 1, 2006 Proceedings will be available at http://dotnet.zcu.cz after the conference.Printed proceedings will be produced for indexing/citation purposes and on request only. CONFERENCE CO-CHAIR - Knoop, Jens (Institute of Computer Languages, Vienna University of Technology, Vienna, Austria)Skala, Vaclav (Department of Computer Science, University of West Bohemia, Plzen, Czech Republic) PROGRAMME COMMITTEE - Aksit, Mehmet (University of Twente, The Netherlands)Giuseppe, Attardi (University of Pisa, Italy)Gough, John (Queensland University of Technology, Australia)Huisman, Marieke (INRIA Sophia Antipolis, France)Knoop, Jens (Vienna University of Technology, Austria)Lengauer, Christian (University of Passau, Germany)Lewis, Brian,T. (Intel Corp., USA)Meijer, Erik (Microsoft, USA) Midkiff, Sam (Purdue University, USA)Ortin, Francisco (University of Oviedo, Spain)Safonov, Vladimir (St. Petersburg University, Russia)Scholz, Bernhard (The University of Sydney, Australia)Siegemund, Frank (European Microsoft Innovation Center, Germany)Skala, Vaclav (University of West Bohemia, Czech Republic)Srisa-an, Witawas (University of Nebraska-Lincoln, USA)Sturm, Peter (University of Trier, Germany)Sullivan, Kevin (University of Virginia, USA)van den Brand, Mark (Technical University of Eindhoven, The Netherlands)Vaswani, Kapil (Indian Institute of Science, India) Veiga, Luis (INESC-ID, Portugal) WEBSITE AND CONTACT For all additional information and information on previous events, please visit the website at http://dotnet.zcu.cz prof.Vaclav Skala, c/o University of West Bohemia, .NET Technologies 2006 conference office Univerzitni 8, Box 314, CZ 306 14 Plzen, Czech Republic [EMAIL PROTECTED] subject: dotnet http://herakles.zcu.cz
[Mono-list] .NET Technologies conference 2006 - OOP, software engineering, etc.
To: mono-list@lists.ximian.com sorry for duplicate if any CALL FOR PAPERS --- .NET TECHNOLOGIES 2006 4th International Conference on .NET Technologies University of West Bohemia Pilsen (Czech Republic) May 29-June 2, 2006 http://dotnet.zcu.cz --- SCOPE AND OBJECTIVES -- The 4rd International Conference on .NET Technologies aims at bringing together practitioners and researchers from academia and the industry to discuss the latest developments in .NET and advance the state of the art in the research on related technologies. Interest in these topics has been continuously growing as a consequence of the importance and the ubiquity of object-oriented technologies. .NET Technologies 2006 builds upon the positive experience of the previous editions of the event, held in Plzen in February 2003, May 2004 and May 2005. TOPICS --- Original papers describing theoretical and practical results (experience reports and case studies) are solicited in the following areas, but not restricted to: - SOFTWARE ENGINEERING: software components, large-scale software, software correctness, software security, - PROGRAMMING LANGUAGES AND TECHNIQUES: object-oriented techniques, programming paradigms, multi-language programming, - PARALLEL AND DISTRIBUTED COMPUTING: multithreading, distributed applications, high-performance computing, web services, - VIRTUAL MACHINES AND BYTECODE, - ASPECT ORIENTED PROGRAMMING AND DEVELOPMENT, - ALGORITHMS AND DATA STRUCTURES, - EDUCATIONAL ASPECTS: teaching object-oriented paradigm with .NET, educational software, - HUMAN COMPUTER INTERFACES: computer graphics, virtual reality with .NET, - SUPPORT FOR .NET ON UNIX: Mono project, ROTOR, DotGNU, Portable.NET, - APPLICATONS of .NET platform - OTHER TOPICS RELATED TO .NET. SUBMISSION GUIDELINES -- Submitted papers must not have been published or concurrently submitted/considered for publication elsewhere. All submissions will be judged on the basis of originality, contribution to the field, technical and presentation quality, and relevance to the conference. Each paper will be refereed by at least 3 reviewers. Presented papers will be included in the conference proceedings with ISBN. Papers should be written in English and not exceed 8 pages in A4 format. Further information and instructions about submissions can be found on the conference website (http://dotnet.zcu.cz/NET_2006.htm). PUBLICATION - The best papers presented at the conference will be published in the Journal of .NET Technology ISSN 1801-2108. Full, short communication papers and posters will be published in proceedings with ISBN. IMPORTANT DATES - Abstract submission:February 14, 2006 Paper submission:February 28, 2006 Author notification:April 14, 2006 Camera-ready papers due: April 30, 2006 Venue: May 30 - June 1, 2006 Proceedings will be available at http://dotnet.zcu.cz after the conference. Printed proceedings will be produced for indexing/citation purposes and on request only. CONFERENCE CO-CHAIR - Knoop, Jens (Institute of Computer Languages, Vienna University of Technology, Vienna, Austria) Skala, Vaclav (Department of Computer Science, University of West Bohemia, Plzen, Czech Republic) PROGRAMME COMMITTEE - Aksit, Mehmet (University of Twente, The Netherlands) Giuseppe, Attardi (University of Pisa, Italy) Gough, John (Queensland University of Technology, Australia) Huisman, Marieke (INRIA Sophia Antipolis, France) Knoop, Jens (Vienna University of Technology, Austria) Lengauer, Christian (University of Passau, Germany) Lewis, Brian,T. (Intel Corp., USA) Meijer, Erik (Microsoft, USA) Ortin, Francisco (University of Oviedo, Spain) Safonov, Vladimir (St. Petersburg University, Russia) Scholz, Bernhard (The University of Sydney, Australia) Siegemund, Frank (European Microsoft Innovation Center, Germany) Skala, Vaclav (University of West Bohemia, Czech Republic) Srisa-an, Witawas (University of Nebraska-Lincoln, USA) Sturm, Peter (University of Trier, Germany) Sullivan, Ken,J. (University of Virginia, USA) van den Brand, Mark (Technical University of Eindhoven, The Netherlands) Veiga, Luis (INESC-ID, Portugal) Watkins, Damien (Microsoft Research, U.K.) WEBSITE AND CONTACT For all additional information and information on previous events, please visit the website at http://dotnet.zcu.cz prof.Vaclav Skala, c/o University of West Bohemia, .NET Technologies 2006 conference office Univerzitni 8, Box 314, CZ 306 14 Plzen, Czech Republic [EMAIL PROTECTED] subject: dotnet
[Mono-list] .Net Framework for Autocad
I am new to Mono. We are a small company that uses Autocad 2005. we would like to run this in Linux so that we can do away with Microsoft all together. The only problem is 2005 requires .Net Framework. Would Mono allow us to use Wine and run Autocad? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net Framework for Autocad
Although this is slightly uneducated, my guess is that Autocad 2005 uses some Windows specific native routines that will not translate to Mono alone. At the same time, I do not believe there is currently a good way to integrate Wine and Mono to basically provide for an equivalent .Net environment. I am not sure the Windows version of Mono can even run under Wine. Therefore, I don't think that the current time you can do what you ask. On 1/6/06, Joe Grobelny [EMAIL PROTECTED] wrote: I am new to Mono. We are a small company that uses Autocad 2005. we would like to run this in Linux so that we can do away with Microsoft all together. The only problem is 2005 requires .Net Framework. Would Mono allow us to use Wine and run Autocad? ___ 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] .Net Membership API Support
I started a projetct on SF to create a Membership that support db4o GPL databases: http://db4omembership.sourceforge.net/ In this version, is implemented: - Create user - Delete user - Login user - Register last login - Send lost password - Change password - Change password question and answer - Update user - List all users Cassio R. Eskelsen2005/11/15, Ben Maurer [EMAIL PROTECTED]: On Mon, 2005-11-14 at 21:43 -0500, Kellner, Peter wrote: Speaking of Membership, is anyone working on that class?If so, is the plan to make a provider for mysql since Microsoft does not have that? Well, there are some basic stubs that I did (a long time ago). ButAFAIK, nobody is working on implementing one of the providers.IMHO, SqlMembershipProvider (if it is implemented) should be written sothat it queries a mssql server with the schema that msft's framework uses -- there would be some value to being able to share anauthentication database with apps that are written on windows. Also, ifsomebody wants to quickly migrate an application from windows to linux,it may be easiest to first do the web part, then the db part. (in fact one app that I am working on for school would benefit greatly from beingable to attach to the MSFT schema).If we want to have a provider that uses a free database (which isneeded), it should probably be a mono specific assembly (that way people on Windows can use it too, if they don't want to pay $1000 forsqlserver (and for some reason can't use don't want sqlexpress). Wecould still make this class the default in Mono's machine.config, sothat things worked out of the box (however, for this to really work, we'd need something like sqlexpress's database attaching).In terms of mysql, pgsql might be a better choice as the mysql provideris now GPL and we are no longer updating it from upstream.-- Ben ___Mono-list maillist-Mono-list@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/mono-list -- Cássio Rogério Eskelsen ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net Membership API Support
Ben Maurer wrote: Well, there are some basic stubs that I did (a long time ago). But AFAIK, nobody is working on implementing one of the providers. IMHO, SqlMembershipProvider (if it is implemented) should be written so that it queries a mssql server with the schema that msft's framework uses -- there would be some value to being able to share an authentication database with apps that are written on windows. Also, if somebody wants to quickly migrate an application from windows to linux, it may be easiest to first do the web part, then the db part. (in fact one app that I am working on for school would benefit greatly from being able to attach to the MSFT schema). Would you send me the database schema for this. It would save me a bit of time on working some of this out. I am a project manager for an open source project writing some portal software that we want to be both .Net and Mono capable. So I am sure part of our project will require us to help out in someone ways with the Mono project too. As a minimum, testing. -- Thomas Miller Chrome Portal Project Manager Wash DC Delphi SIG Chairperson Delphi Client/Server Certified Developer BSS Accounting Distribution Software BSS Enterprise Accounting FrameWork http://www.bss-software.com http://www.cpcug.org/user/delphi/index.html http://sourceforge.net/projects/chromeportal/ http://sourceforge.net/projects/uopl/ http://sourceforge.net/projects/dbexpressplus ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] .Net Membership API Support
I know this is probably really early to ask, but is this likely to make it into Mono for .Net 2 -- Thomas Miller Chrome Portal Project Manager Wash DC Delphi SIG Chairperson Delphi Client/Server Certified Developer BSS Accounting Distribution Software BSS Enterprise Accounting FrameWork http://www.bss-software.com http://www.cpcug.org/user/delphi/index.html http://sourceforge.net/projects/chromeportal/ http://sourceforge.net/projects/uopl/ http://sourceforge.net/projects/dbexpressplus ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net Membership API Support
Hello, I know this is probably really early to ask, but is this likely to make it into Mono for .Net 2 Yes, it will be eventually supported. Miguel. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net Membership API Support
Hello, I know this is probably really early to ask, but is this likely to make it into Mono for .Net 2 Yes, it will be eventually supported. I forgot to mention: the best way of getting this supported in a timely fashion is to contribute an implementation ;-) You could either contribute here, or contribute in other areas, which would free up developer time to get to this feature. miguel. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] .Net Membership API Support
Speaking of Membership, is anyone working on that class? If so, is the plan to make a provider for mysql since Microsoft does not have that? thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Miguel de Icaza Sent: Monday, November 14, 2005 2:38 PM To: [EMAIL PROTECTED] Cc: mono-list@lists.ximian.com Subject: Re: [Mono-list] .Net Membership API Support Hello, I know this is probably really early to ask, but is this likely to make it into Mono for .Net 2 Yes, it will be eventually supported. I forgot to mention: the best way of getting this supported in a timely fashion is to contribute an implementation ;-) You could either contribute here, or contribute in other areas, which would free up developer time to get to this feature. miguel. ___ 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] .Net Membership API Support
On Mon, 2005-11-14 at 21:43 -0500, Kellner, Peter wrote: Speaking of Membership, is anyone working on that class? If so, is the plan to make a provider for mysql since Microsoft does not have that? Well, there are some basic stubs that I did (a long time ago). But AFAIK, nobody is working on implementing one of the providers. IMHO, SqlMembershipProvider (if it is implemented) should be written so that it queries a mssql server with the schema that msft's framework uses -- there would be some value to being able to share an authentication database with apps that are written on windows. Also, if somebody wants to quickly migrate an application from windows to linux, it may be easiest to first do the web part, then the db part. (in fact one app that I am working on for school would benefit greatly from being able to attach to the MSFT schema). If we want to have a provider that uses a free database (which is needed), it should probably be a mono specific assembly (that way people on Windows can use it too, if they don't want to pay $1000 for sqlserver (and for some reason can't use don't want sqlexpress). We could still make this class the default in Mono's machine.config, so that things worked out of the box (however, for this to really work, we'd need something like sqlexpress's database attaching). In terms of mysql, pgsql might be a better choice as the mysql provider is now GPL and we are no longer updating it from upstream. -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
