Re: [Mono-dev] [PATCH] AssemblyName.ctor () can't parse ProcessorArchitecture.
On 05/07/07 Paolo Molaro wrote: Sadly MonoAssemblyName is exported in a public header and can't be changed: it would be an ABI change, which we can't do until mono 2.0. This means that the changes required are more complex. One idea is to define a MonoInternalAssemblyName, make it embed a MonoAssemblyName field and add the additional fields (cpu_arch). Then all the internal functions that take a MonoAssemblyName should be changed to take a MonoInternalAssemblyName instead. It may also be better, depending on the amount of changes to not embed MonoAssemblyName in MonoInternalAssemblyName, but to simple have the same fields in it. As this takes some time, I committed to svn a change to parse ProcessorArchitecture and ignore it for now. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] FastCGI, was: Silverlight early implementation thoughts.
Hey Marek, Marek Habersack wrote: This is still much easier to cope with than mod_mono abrakadabra, IMHO :) Even if some people will consider it to be harder, the configuration above is specific to apache only and with FastCGI we will be able to use any other webserver that supports the protocol. This is, in my eyes, the biggest advantage of having such bridge (in addition to using a standard, well-supported protocol to handle the requests). W/out any doubt, fastcgi has a lot of advantages. I don't want to criticize it. Just its configuration could be a problem for apache newbies, but ... Configuring an application-to-mono-process mapping, easily to achieve with mod_mono, will become a nightmare with FastCGI. Moreover, the config snippets above must be inserted in every vhost, otherwise the vhosts will share the same mono-fastcgi-server process. That's not entirely true. Please read http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiWrapper With the help of the above you can create a dynamic setup that suits your needs. ... if Mono will provide its own configuration manager using a wrapper (which hopefully won't badly interfere with other fastcgi apps (e.g. php) on the same server), I'm fine with it :-) Are there any plans to make the wrapper interactive (a web app of its own), like a small application server? Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mod_mono, fast_cgi and configuration.
Miguel de Icaza wrote: Do you have some ideas on what we could do to make mod_mono simpler to configure? And do people have some thoughts on what we could do to improve mod_mono? Which areas are particularly weak, and what can we do to improve it? I know you directed the first question at Robert but as a new user to mod_mono, I do not find the configuration complicated once it is working. The biggest problem I faced was that the documentation to get a working mod_mono apache configuration is spread out throughout http://www.mono-project.com/Mod_mono and you have to figure it out for yourself. There is also a lot of out-dated information on that page for old versions of mod_mono(see the Paths section, for instance). I think the page just needs to be trimmed down and streamlined. But the apache configuration itself is pretty straight forward, here is mine right now: Directory /www/mono-test Order allow,deny Allow from all /Directory Alias /test /www/mono-test AddMonoApplications test /test:/www/mono-test MonoServerPath test /usr/local/bin/mod-mono-server2 Location /test MonoSetServerAlias test SetHandler mono /Location As far as improvements, the one thing I would love to see is dynamic recompilation of code behind files. It kind of sucks right now that I have to restart my server through mod_mono Control Panel page for every code update when I am just playing with stuff in a shell. I do not know how feasible it would be to support this but it sure would be nice. If this is a web.config issue, I would love to be pointed in the right direction. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mod_mono, fast_cgi and configuration.
On Tue, 08 May 2007 08:30:17 -0500, Ted Milker [EMAIL PROTECTED] scribbled: Hello Ted, [snip] As far as improvements, the one thing I would love to see is dynamic recompilation of code behind files. It kind of sucks right now that I have to restart my server through mod_mono Control Panel page for every code update when I am just playing with stuff in a shell. I do not know how feasible it would be to support this but it sure would be nice. If this is a web.config issue, I would love to be pointed in the right direction. This support is in mono 1.2.4 - please give it a try to see if it works as you expect it to. best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] monoburg and eglib
On 05/04/07 Andreas Färber wrote: I'm wondering why monoburg uses a nonstandard way of building? Instead of declaring the usual automake variables noinst_PROGRAMS and ..._SOURCES it invokes $CC_FOR_BUILD to build monoburg $BUILD_EXEEXT. Is this to allow cross-compiling? Yes. Unfortunately this way of building breaks on Mac OS X when using eglib because gcc is directly being passed eglib's .la file in place of the usual -lglib-2.0 flag. How should this be fixed? When not cross-compiling you might want to set BUILD_GLIB_LIBS and BUILD_GLIB_CFLAGS to GLIB_LIBS and GLIB_CFLAGS in configure.in. When cross-compiling a different eglib would need to be compiled. Another solution is to remove glib use from monoburg, the stuff used is quite small (and a fixed-size hash table is good enough for this tool, the rest is just a list imple, basically). lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NHibernate 1.2 problem on mono 1.2.4 preview
On 05/06/07 Pascal Fresnay wrote: It seems that the new NHibernate major release (1.2 - 3 may 2007) can't be used on mono, a method is missing that throw a NotImplementedException ( http://bugzilla.ximian.com/show_bug.cgi?id=78637 ) in auto-generated proxies. Any chance to have a fix in 1.2.4 release ? I fixed this in svn, though it most likely won't be in 1.2.4 since that has already been tagged and this is not a regression fix. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] patch application.cs
Hi, This is a small patch to add stub and some code for Application class. regards, Duff Application patch.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] monoburg and eglib
Hi Paolo, this way of building breaks on Mac OS X when using eglib because gcc is directly being passed eglib's .la file in place of the usual -lglib-2.0 flag. How should this be fixed? When not cross-compiling you might want to set BUILD_GLIB_LIBS and BUILD_GLIB_CFLAGS to GLIB_LIBS and GLIB_CFLAGS in configure.in. As far as I can tell this is already being done. The problem is rather with [BUILD_]GLIB_LIBS being applied to *gcc* in one step instead of doing .c -(gcc) .o; .o + .la -(*libtool*) monoburg. This is independent of cross-compiling or not. Unfortunately the auto* manuals have not shed any light on what variables to use in place of CC_FOR_BUILD to continue to allow cross- compiling while fixing this for OS X (the simplest fix for me was to use the usual automake way of building but that breaks cross-compiling). Also, in theory I *am* actually cross-compiling from ppc to ppc64, only does Apple's (or Solaris') gcc not use the classic way of cross-compiling but stuffs this functionality via custom switches into one gcc so that configure does not know about it. (On both platforms uname -a does not indicate what exact platform I am on and the target platform is set using -arch architecture, not by selecting a different gcc executable.) On OS X v10.4 the only 64-bit library is libSystem (=libc), and compiling glib for ppc64 failed, thus I have patched eglib to have a glib at all. So given that there is no distinction between host and target I do not see a way how I could easily compile part of Mono 32- bit w/[e]glib and another 64-bit w/eglib, which would be the best solution for the eglib/test trouble (which assumes there is a usable glib and tries to compile against it as part of make). When cross-compiling a different eglib would need to be compiled. What do you mean by this? Another solution is to remove glib use from monoburg, the stuff used is quite small (and a fixed-size hash table is good enough for this tool, the rest is just a list imple, basically). Well, the whole point of [e]glib is to avoid rewriting code everyplace, no? It would therefore seem more efficient to fix this simple build issue for now and only at some point in the future enhance Mono's cross-compilation support in general. Btw I've already had a shot at fixing some VPATH issues with eglib and Mono and hope to provide a patch end of the week. Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [patch] Add DSA support to CryptConvert
Hello Randolph,
On Tue, 2007-05-08 at 07:00 +0800, Randolph Chung wrote:
The attached patch adds support to convert DSA blobs in
Mono.Security.CryptoConvert. Once this is in, minor and obvious changes
to System.Security.Cryptography.DSACryptoServiceProvider can be made to
implement the ImportCspBlob and ExportCspBlob() methods.
It looks great. There are only some minor coding style issue, maybe
editor related, that should be fixed before committing this into SVN.
http://www.mono-project.com/Coding_Guidelines
Comments appreciated :)
Thanks for supplying unit tests with your work!
randolph
plain text document attachment (mono-dsa.diff)
2007-05-07 Randolph Chung [EMAIL PROTECTED]
* CryptoConvert.cs: Implement DSA blob conversion functions.
Index: class/Mono.Security/Mono.Security.Cryptography/CryptoConvert.cs
===
--- class/Mono.Security/Mono.Security.Cryptography/CryptoConvert.cs
(revision 76866)
+++ class/Mono.Security/Mono.Security.Cryptography/CryptoConvert.cs
(working copy)
@@ -183,6 +183,70 @@
}
}
+ static public DSA FromCapiPrivateKeyBlobDSA(byte[] blob)
missing space before (
+ {
+ return FromCapiPrivateKeyBlobDSA(blob, 0);
+ }
+
+ static public DSA FromCapiPrivateKeyBlobDSA(byte[] blob, int
offset)
+ {
+ if (blob == null)
+ throw new ArgumentNullException(blob);
+ if (offset = blob.Length)
+ throw new ArgumentException(blob is too
small.);
+
+ try
+ {
{ on the same line as try
+ if ((blob[offset] != 0x07) ||
// PRIVATEKEYBLOB (0x07)
+ (blob[offset + 1] != 0x02) ||
// Version (0x02)
+ (blob[offset + 2] != 0x00) ||
// Reserved (word)
+ (blob[offset + 3] != 0x00) ||
+ (ToUInt32LE(blob, offset + 8) !=
0x32535344)) // DWORD magic
+ throw new
CryptographicException(Invalid blob header);
+
+ int bitlen = ToInt32LE(blob, offset + 12);
+ DSAParameters dsap = new DSAParameters();
+ int bytelen = bitlen 3;
+ int pos = offset + 16;
+
+ dsap.P = new byte[bytelen];
+ Buffer.BlockCopy(blob, pos, dsap.P, 0, bytelen);
+ Array.Reverse(dsap.P);
+ pos += bytelen;
+
+ dsap.Q = new byte[20];
+ Buffer.BlockCopy(blob, pos, dsap.Q, 0, 20);
+ Array.Reverse(dsap.Q);
+ pos += 20;
+
+ dsap.G = new byte[bytelen];
+ Buffer.BlockCopy(blob, pos, dsap.G, 0, bytelen);
+ Array.Reverse(dsap.G);
+ pos += bytelen;
+
+ dsap.X = new byte[20];
+ Buffer.BlockCopy(blob, pos, dsap.X, 0, 20);
+ Array.Reverse(dsap.X);
+ pos += 20;
+
+ dsap.Counter = ToInt32LE(blob, pos);
+ pos += 4;
+
+ dsap.Seed = new byte[20];
+ Buffer.BlockCopy(blob, pos, dsap.Seed, 0, 20);
+ Array.Reverse(dsap.Seed);
+ pos += 20;
+
+ DSA dsa = (DSA)DSA.Create();
+ dsa.ImportParameters(dsap);
+ return dsa;
+ }
+ catch (Exception e)
+ {
{ on the same line as catch
+ throw new CryptographicException(Invalid
blob., e);
+ }
+ }
+
static public byte[] ToCapiPrivateKeyBlob (RSA rsa)
{
RSAParameters p = rsa.ExportParameters (true);
@@ -255,6 +319,60 @@
return blob;
}
+ static public byte[] ToCapiPrivateKeyBlob(DSA dsa)
+ {
+ DSAParameters p = dsa.ExportParameters(true);
+ int keyLength = p.P.Length; // in bytes
+
+ // header + P + Q + G + X + count + seed
+ byte[] blob = new byte[16 + keyLength + 20 + keyLength
+ 20 + 4 + 20];
+
+
Re: [Mono-dev] [patch] Add DSA support to CryptConvert
It looks great. There are only some minor coding style issue, maybe
editor related, that should be fixed before committing this into SVN.
Thanks for the review and comments. Patch updated. Please apply if ok.
randolph
mcs/class/Mono.Security/Mono.Security.Cryptography:
mcs/class/corlib/Mono.Security.Cryptography:
2007-05-08 Randolph Chung [EMAIL PROTECTED]
* CryptoConvert.cs: Add DSA blob conversion functions.
mcs/class/Mono.Security/Test/Mono.Security.Cryptography:
2007-05-08 Randolph Chung [EMAIL PROTECTED]
* CryptoConvertTest.cs: Add tests for DSA conversion functions.
Index: CryptoConvert.cs
===
--- CryptoConvert.cs(revision 76876)
+++ CryptoConvert.cs(working copy)
@@ -183,6 +183,68 @@
}
}
+ static public DSA FromCapiPrivateKeyBlobDSA (byte[] blob)
+ {
+ return FromCapiPrivateKeyBlobDSA (blob, 0);
+ }
+
+ static public DSA FromCapiPrivateKeyBlobDSA (byte[] blob, int
offset)
+ {
+ if (blob == null)
+ throw new ArgumentNullException (blob);
+ if (offset = blob.Length)
+ throw new ArgumentException (blob is too
small.);
+
+ try {
+ if ((blob [offset] != 0x07) ||
// PRIVATEKEYBLOB (0x07)
+ (blob [offset + 1] != 0x02) ||
// Version (0x02)
+ (blob [offset + 2] != 0x00) ||
// Reserved (word)
+ (blob [offset + 3] != 0x00) ||
+ (ToUInt32LE (blob, offset + 8) !=
0x32535344)) // DWORD magic
+ throw new CryptographicException
(Invalid blob header);
+
+ int bitlen = ToInt32LE (blob, offset + 12);
+ DSAParameters dsap = new DSAParameters ();
+ int bytelen = bitlen 3;
+ int pos = offset + 16;
+
+ dsap.P = new byte [bytelen];
+ Buffer.BlockCopy (blob, pos, dsap.P, 0,
bytelen);
+ Array.Reverse (dsap.P);
+ pos += bytelen;
+
+ dsap.Q = new byte [20];
+ Buffer.BlockCopy (blob, pos, dsap.Q, 0, 20);
+ Array.Reverse (dsap.Q);
+ pos += 20;
+
+ dsap.G = new byte [bytelen];
+ Buffer.BlockCopy (blob, pos, dsap.G, 0,
bytelen);
+ Array.Reverse (dsap.G);
+ pos += bytelen;
+
+ dsap.X = new byte [20];
+ Buffer.BlockCopy (blob, pos, dsap.X, 0, 20);
+ Array.Reverse (dsap.X);
+ pos += 20;
+
+ dsap.Counter = ToInt32LE (blob, pos);
+ pos += 4;
+
+ dsap.Seed = new byte [20];
+ Buffer.BlockCopy (blob, pos, dsap.Seed, 0, 20);
+ Array.Reverse (dsap.Seed);
+ pos += 20;
+
+ DSA dsa = (DSA)DSA.Create ();
+ dsa.ImportParameters (dsap);
+ return dsa;
+ }
+ catch (Exception e) {
+ throw new CryptographicException (Invalid
blob., e);
+ }
+ }
+
static public byte[] ToCapiPrivateKeyBlob (RSA rsa)
{
RSAParameters p = rsa.ExportParameters (true);
@@ -255,6 +317,60 @@
return blob;
}
+ static public byte[] ToCapiPrivateKeyBlob (DSA dsa)
+ {
+ DSAParameters p = dsa.ExportParameters (true);
+ int keyLength = p.P.Length; // in bytes
+
+ // header + P + Q + G + X + count + seed
+ byte[] blob = new byte [16 + keyLength + 20 + keyLength
+ 20 + 4 + 20];
+
+ blob [0] = 0x07;// Type - PRIVATEKEYBLOB (0x07)
+ blob [1] = 0x02;// Version - Always
CUR_BLOB_VERSION (0x02)
+ // [2], [3] // RESERVED - Always 0
+ blob [5] = 0x22;// ALGID
+ blob [8] = 0x44;// Magic
+ blob [9] = 0x53;
+
[Mono-dev] [patch] Fix some bugs in the DataGridView control
In a test application I ran across some problems with the current
DataGridView control. Attached is a patch that fixes one particular area
of problems.
The original issue I ran into is that trying to address a cell in a grid
by its column name fails, because the cell's owningcolumn attribute was
never set. In looking into this, I also ran into problems with how the
grid currently creates rows and cells from their templates (in the
latter case, it appears we previously do not use the cell templates at
all). I've updated the implementation so that the templates are used and
that the owningColumn attribute gets set properly. To complete this
change I also added some error checks and updated the return value of
SetValues() so that it matches the MS.NET implementation.
Four new unit tests were added to the testsuite.
Please review and commit if ok.
thanks
randolph
mcs/class/Managed.Windows.Forms/System.Windows.Forms:
2007-05-08 Randolph Chung [EMAIL PROTECTED]
* DataGridViewRowCollection.cs: Properly create rows and cells from
their templates and set their owning column attributes. Update handling
of adding rows without columns and shared rows so that it matches the
MS.NET behavior.
* DataGridViewColumnCollection: Create new columns as TextBox columns
instead of generic (unpaintable) columns.
* DataGridViewRow.cs: Do not allow balues to be set on a shared row.
Do not spontaneously create cells in SetValues () if the cells do not
already exist. Properly set the return value according to what got
added to the row.
* DataGridViewCell.cs: Remove uninitialized dataGridViewOwner attribute.
Use the base class' DataGridView properly where required.
mcs/class/Managed.Windows.Forms/Test/System.Windows.Forms:
2007-05-08 Randolph Chung [EMAIL PROTECTED]
* DataGridViewRowTest.cs: Update existing tests based on changes to
row behavior. Add new tests for new error checks and return values.
Index: DataGridViewRowCollection.cs
===
--- DataGridViewRowCollection.cs(revision 76876)
+++ DataGridViewRowCollection.cs(working copy)
@@ -87,26 +87,41 @@
public event CollectionChangeEventHandler CollectionChanged;
+ private DataGridViewRow CreateRowFromTemplate () {
+ DataGridViewRow row = dataGridView.RowTemplate.Clone ()
as DataGridViewRow;
+ row.SetDataGridView (dataGridView);
+ foreach (DataGridViewColumn col in
dataGridView.Columns) {
+ DataGridViewCell cell = col.CellTemplate.Clone
() as DataGridViewCell;
+ cell.SetOwningColumn (col);
+ row.Cells.Add (cell);
+ }
+ return row;
+ }
+
[DesignerSerializationVisibility
(DesignerSerializationVisibility.Hidden)]
public virtual int Add ()
{
- return Add(dataGridView.RowTemplate.Clone() as
DataGridViewRow);
+ return Add(CreateRowFromTemplate(), true);
}
int IList.Add(object o)
{
- return Add(o as DataGridViewRow);
+ return Add(o as DataGridViewRow, false);
}
- public virtual int Add (DataGridViewRow dataGridViewRow)
+ private int Add (DataGridViewRow dataGridViewRow, bool
fromTemplate)
{
+ if (dataGridView.Columns.Count == 0) {
+ throw new InvalidOperationException (No row
can be added to a DataGridView control that does not have columns. Columns must
be added first.);
+ }
if (dataGridView.DataSource != null) {
throw new InvalidOperationException(DataSource
of DataGridView is not null.);
}
if (dataGridView.Columns.Count == 0) {
throw new
InvalidOperationException(DataGridView has no columns.);
}
- dataGridViewRow.SetIndex(list.Count);
+ if (fromTemplate)
+ dataGridViewRow.SetIndex(list.Count);
dataGridViewRow.SetDataGridView(dataGridView);
int result = list.Add(dataGridViewRow);
OnCollectionChanged(new
CollectionChangeEventArgs(CollectionChangeAction.Add, dataGridViewRow));
@@ -116,6 +131,11 @@
return result;
}
+ public virtual int Add (DataGridViewRow dataGridViewRow)
+ {
+ return Add (dataGridViewRow, false);
+
[Mono-dev] [PATCH] C# 3.0 Feature: Automatic Properties
This patch implements the automatic properties feature of C# 3.0 as demoed
by Anders Hejlsberg at Mix (
http://int1.fp.sandpiper.net/soma/applications/silverlight/v1/videos/DEV04.wmv
at
12 minutes, 40 seconds). Please vet!
--
Scott.
Index: tests/gtest-autoproperty-01.cs
===
--- tests/gtest-autoproperty-01.cs (revision 0)
+++ tests/gtest-autoproperty-01.cs (revision 0)
@@ -0,0 +1,27 @@
+// Compiler options: -langversion:linq
+// Tests automatic properties
+using System;
+
+public class Test
+{
+ public string Foo { get; set; }
+ public int Answer { get; private set; }
+
+ public Test ()
+ {
+ Answer = 42;
+ }
+
+ static int Main ()
+ {
+ Test t = new Test ();
+ t.Foo = Bar;
+ if (t.Foo != Bar)
+ return 1;
+
+ if (t.Answer != 42)
+ return 2;
+
+ return 0;
+ }
+}
Index: gmcs/cs-parser.jay
===
--- gmcs/cs-parser.jay (revision 76948)
+++ gmcs/cs-parser.jay (working copy)
@@ -1514,9 +1514,23 @@
if (name.TypeArguments != null)
syntax_error (lexer.Location, a property can't have type arguments);
- prop = new Property (current_class, (Expression) $3, (int) $2, false,
+ Expression type = (Expression) $3;
+ int mod = (int) $2;
+ // Check that:
+ if (RootContext.Version = LanguageVersion.LINQ // * This is C# 3.0
+ (mod (Modifiers.ABSTRACT | Modifiers.EXTERN)) == 0 // * The property is not abstract or external
+ get_block != null set_block != null // * Both accessors exist
+ get_block.Block == null set_block.Block == null) { // * Neither accessor has a body
+ if (get_block != null)
+get_block.Block = make_accessor_block (type, true);
+ if (set_block != null)
+set_block.Block = make_accessor_block (type, false);
+ current_accessor_field = null;
+ }
+
+ prop = new Property (current_class, type, mod, false,
name, (Attributes) $1, get_block, set_block, accessors.declared_in_reverse);
-
+
current_container.AddProperty (prop);
implicit_value_parameter_type = null;
@@ -5887,5 +5901,35 @@
return retval;
}
+Field current_accessor_field;
+ToplevelBlock make_accessor_block (Expression type, bool get)
+{
+ if (current_accessor_field == null) {
+ current_accessor_field = new Field (current_container, implicit_value_parameter_type,
+ Modifiers.PRIVATE, CompilerGeneratedClass.MakeName (CompilerGeneratedField),
+ null, Location.Null);
+ current_container.AddField (current_accessor_field);
+ }
+
+ Parameter value = new Parameter (type, value, Parameter.Modifier.NONE, null, Location.Null);
+ Parameters parameters = new Parameters (new Parameter [] { value });
+
+ ToplevelBlock block = new ToplevelBlock (current_block, parameters, Location.Null);
+ This t = new This (block, Location.Null);
+ MemberAccess ma = new MemberAccess (t, current_accessor_field.Name);
+
+ if (get) {
+ Return r = new Return (ma, Location.Null);
+ block.AddStatement (r);
+ }
+ else {
+ SimpleName sn = new SimpleName (value, Location.Null);
+ Assign a = new Assign (ma, sn);
+ block.AddStatement (new StatementExpression(a));
+ }
+
+ return block;
+}
+
/* end end end */
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [patch] Implement DSACryptoServiceProvider.{ExportCspBlob, ImportCspBlob}
Applied to SVN.
Thanks (again :-)
On Wed, 2007-05-09 at 05:49 +0800, Randolph Chung wrote:
This is a follow-on patch to the CryptoConvert patch to use those newly
implemented functions to implement the two missing methods in
DSACryptoServiceProvider.
Please review and apply.
randolph
plain text document attachment (dsa2.diff)
mcs/class/corlib/System.Security.Cryptography:
2007-05-08 Randolph Chung [EMAIL PROTECTED]
* DSACryptoServiceProvider.cs: Implement the ImportCspBlob and
ExportCspBlob methods by calling into CryptoConvert.
mcs/class/corlib/Test/System.Security.Cryptography:
2007-05-08 Randolph Chung [EMAIL PROTECTED]
* DSACryptoServiceProviderTest.cs: Remove NotWorking annotation
for the blob tests that should now pass.
Index: DSACryptoServiceProvider.cs
===
--- DSACryptoServiceProvider.cs (revision 76876)
+++ DSACryptoServiceProvider.cs (working copy)
@@ -277,20 +277,39 @@
get { return null; }
}
- [MonoTODO (call into CryptoConvert (doesn't currently support
DSA))]
[ComVisible (false)]
public byte[] ExportCspBlob (bool includePrivateParameters)
{
- throw new NotImplementedException (CryptoConvert
doesn't currently support DSA);
+ byte[] blob = null;
+ if (includePrivateParameters)
+ blob = CryptoConvert.ToCapiPrivateKeyBlob
(this);
+ else
+ blob = CryptoConvert.ToCapiPublicKeyBlob (this);
+ return blob;
}
- [MonoTODO (call into CryptoConvert (doesn't currently support
DSA))]
[ComVisible (false)]
public void ImportCspBlob (byte[] rawData)
{
if (rawData == null)
throw new ArgumentNullException (rawData);
- throw new NotImplementedException (CryptoConvert
doesn't currently support DSA);
+ DSA dsa = CryptoConvert.FromCapiKeyBlobDSA (rawData);
+ if (dsa is DSACryptoServiceProvider) {
+ DSAParameters dsap = dsa.ExportParameters
(!(dsa as DSACryptoServiceProvider).PublicOnly);
+ ImportParameters (dsap);
+ } else {
+ // we can't know from DSA if the private key is
available
+ try {
+ // so we try it...
+ DSAParameters dsap =
dsa.ExportParameters (true);
+ ImportParameters (dsap);
+ }
+ catch {
+ // and fall back
+ DSAParameters dsap =
dsa.ExportParameters (false);
+ ImportParameters (dsap);
+ }
+ }
}
#endif
}
Index: DSACryptoServiceProviderTest.cs
===
--- DSACryptoServiceProviderTest.cs (revision 76876)
+++ DSACryptoServiceProviderTest.cs (working copy)
@@ -966,7 +966,6 @@
}
[Test]
- [Category (NotWorking)]
public void ExportCspBlob_Full ()
{
dsa = new DSACryptoServiceProvider (minKeySize);
@@ -978,7 +977,6 @@
}
[Test]
- [Category (NotWorking)]
public void ExportCspBlob_PublicOnly ()
{
dsa = new DSACryptoServiceProvider (minKeySize);
@@ -991,7 +989,6 @@
[Test]
[ExpectedException (typeof (CryptographicException))]
- [Category (NotWorking)]
public void ExportCspBlob_MissingPrivateKey ()
{
dsa = new DSACryptoServiceProvider (minKeySize);
@@ -1002,7 +999,6 @@
}
[Test]
- [Category (NotWorking)]
public void ExportCspBlob_MissingPrivateKey_PublicOnly ()
{
dsa = new DSACryptoServiceProvider (minKeySize);
@@ -1014,7 +1010,6 @@
}
[Test]
- [Category (NotWorking)]
public void ImportCspBlob_Keypair ()
{
byte[] blob = new byte [336] { 0x07, 0x02, 0x00, 0x00, 0x00,
0x22, 0x00, 0x00, 0x44, 0x53, 0x53, 0x32, 0x00, 0x04, 0x00, 0x00, 0xD3,
@@ -1042,7 +1037,6 @@
}
[Test]
- [Category (NotWorking)]
public void ExportCspBlob_PublicKey ()
{
byte[] blob = new byte [444] { 0x06, 0x02, 0x00, 0x00, 0x00,
0x22, 0x00, 0x00, 0x44, 0x53, 0x53, 0x31, 0x00, 0x04, 0x00, 0x00, 0xD3,
@@ -1084,7 +1078,6 @@
[Test]
[ExpectedException (typeof
