[Mono-list] AssemblyVersionAttribute not showing up?
I've created an AssemblyInfo.cs file, and set the AssemblyTitleAttribute, AssemblyVersionAttribute, and AssemblyCopyrightAttribute within. I've also ensured that the System.Reflection namespace is being used. However, when I try to use the GetCustomAttributes method on the currently executing assembly, the only Attributes it returns are the Title and Copyright Attributes. No Version. Is there any reason that an AssemblyVersionAttribute wouldn't be accessible through this way, even though other attributes set in AssemblyInfo.cs are? -- Stephen Touset [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Implementing attribute-based code generation
Shawn Vose wrote: Use System.Reflection to read available methods, attributes and properties for a dll. You can use it to do so at runtime. I know there has been a few questions and answers on Relection in the archives What I'm trying to accomplish is slightly different, and cannot be done with the current design of attributes. As an example, I want to be able to place preconditions and postconditions on methods and invariants on classes. These attributes need to follow inheritance rules for Design By Contract as well: postconditions are logically ORed with any inherited postconditions from base classes, while postconditions and invariants are logically ANDed with inherited ones from their base classes. This is not possible with the current implementation of attributes. Nor is the ability for an attribute to consitently, automatically, and predictable modify the way a method or class works. Attributes cannot access the methods they belong to, nor can they generate code dynamically. There is also no way to have them transparently invoke code upon method execution. Because of this, something would need to be written to have certain attributes generate code in the methods they modify, or in all the methods of the classes they modify. Also, these attributes would need to be inherited upon their base classes as well, automatically. A script could theoretically do it, but that would require a lot of additional work, reimplementing a C# parser that already exists with Mono. If you can find a way to do this with System.Reflection, please let me know. It would save me a bundle of time. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Implementing attribute-based code generation
Dan Maltes wrote: This sounds very interesting. How much runtime control would we have over attribute values? Could runtime change of attribute trigger a jit, or would this become unstable and/or poor performance? I'd like to start small. My intention is to make an Extension interface/abstract class which provides hooks for different aspects of the compilation process. A .dll could be loaded at mcs runtime which provides code for these hooks, which are then called at the respective points in the compilation process. This way these extra features could be kept out of mcs proper. This is certainly a possibility, but I believe it would have to be done in the mono jit, rather than in mcs. I'm hoping right now for compile-time adjustments to code rather than jit-time. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] YUM repository
On Wed, 2005-01-12 at 14:45 +, Colin JN Breame wrote: b) any chance of gettting an apt repository? Debian provides mono as part of their testing and unstable distributions. As far as I can tell, they're quite close to upstream. -- Stephen Touset [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
[Mono-list] Implementing attribute-based code generation
I'm looking into the potential of writing code to allow mono to have extensions. As a first foray into the idea, I'm going to try writing a module that would look for specific attributes on methods and classes, and use those to generate code that would go into the marked methods and all methods of the marked classes, respectively. However, looking at the mono source code, it seems to be very complex. I'm looking for hints as to the best place to put the hooks for the extension, because of this. My first idea would be to put this after the parsing of the source tree, so that I can manipulate the methods as they're in memory. However, I can't seem to find simple ways to navigate through the memory representation of the source tree. Can anyone give me a brief pointer to where I should be looking? -- Stephen Touset [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Mono-list] Implementing attribute-based code generation
Rodrigo B. de Oliveira wrote:
It sounds like you are talking about what we call syntactic attributes.
I couldn't tell from the website. Essentially, I am trying to add design
by contract support to the mono C# compiler (as an extension, rather
than a core patch to mcs). The best way to do this would seem to be to
have attributes that can modify methods. In other words:
[Precondition(o != null)]
[Postcondition(size 0)]
void AddObject(Object o) {
// ... do stuff ...
return;
}
Which would then at compile time insert
void AddObject(Object o) {
Check.Require(o != null);
// ... do stuf ...
Check.Ensure(size 0);
return;
}
While also obeying design by contract inheritance rules.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Design by Contract
On Fri, 2004-12-31 at 18:17 -0500, Robert Shade wrote: Just to add my two cents, I think I would discourage the attribute idea. For one, it would mean that your compiled application would have to link with your DBC library. This would mean that the user would have to deal with a bunch of #if's so that those attributes would not be compiled in production code. Otherwise, the user would be forced to distribute your library with their product. Well, there wouldn't be a lot of #if statements, as far as I know. A failure of the preconditions indicates that there's a bug in your user's code. A failure of the postconditions or invariants indicates that a bug exists in your code. Because of this, there are really two use cases (although a bit more fine-grained tuning could be used without requiring you to be overly verbose). Firstly, debugging. You want everything on. That way, you can ensure that your code is working as expected. If any postconditions or invariants fail, you know that your code is not holding up its end of the bargain.. The second case is in release code. You want only preconditions on. The postcondition and invariant checks will probably be too slow to use in release code, and by that time you've already (theoretically) debugged your application. Unit testing combined with postconditions/invariants should discover a significant number of those bugs, and give you the confidence to disable them. Preconditions, however, would still be enabled. Since most functions already put lines in the beginning of functions anyways to test variable constraints, this would simply shift the placement of these tests from code to metadata. Secondly, attributes would force the checking to be done by a modified compiler. This would seriously limit your target audience to mono folks. Love mono, but the masses are using Microsoft's compiler. Yeah =\ An external tool would also allow you to investigate the code flow in ways that the compiler may not. For example, you could do process time checking of the code to see if your contracts are always true/false. (I belive the MS compiler does this for conditionals) For things that were marked invariant, you could follow the code flow to see if these are modified at any point. You'd perhaps even be able to warn the user under exactly what conditions the contracts would fail. If you had that functionality, you would completely eliminate the need for the user to have the (runtime) contract checking code present. The user would already know precisely under what conditions errors would occur and could add exception handling to take care of it. I'm not quite sure if this kind of approach would work. Design By Contract explicitly states when contracts need to be checked, so having an external application that does process-time checking would be difficult to implement in this way. Also, preconditions are something you (almost) always want checked, so requiring a third-party application in this case seems even worse than a third-party library. Especially so, because any libraries which implement Design By Contract would then be forced to redistribute the application, and their clients would be forced to run it. In all, I want to avoid having to write a bottom-up parser for C#, or even rip out mcs' C# parser, and use it for my own needs. Is there some method of putting hooks into mcs, so that I don't have to modify the mcs code itself? -- Stephen Touset [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Mono-list] Design by Contract
On Tue, 2004-12-28 at 20:31 -0500, Joshua Tauberer wrote: I've thought about this a few times and even tried hacking some rudimentary DBC support into Mono using attributes. The difficulty in this depends on what you want out of DBC. I was going for something that would see contract violations at compile time (which turned out to be way over my head, so I didn't get far). Just adding assertions automatically would be much easier, or even easy. I was just looking for runtime checking of contract violations, not compile-time. Adding pre/post-condition assertions would just mean going into the parts of mcs for methods and properties, looping through the attributes on the method/parameters, and adding some object creations (to instantiate the attributes) and method invocations (to have the attribute perform the check) in the generated IL. Not much, really. Well...this was actually my next step: adding support in mcs. However, I don't really have the desire to maintain a fork of mcs, and I was hoping to test the water to see if this is something that the mono folks would be opposed to, since it's not strictly C#. From rom what I can tell, there appears to be no way to add the ability to do DBC-like checking to C# programs without modifying the compiler itself. A perl script could theoretically just convert attributes into code, but contract inheritance quickly becomes a thorny issue. So, is support for DBC something that anyone would be willing to see in mcs? Is it even something the mcs folks would allow as a patch, or would I need to maintain a separate fork of mcs (something I'm not really willing to do)? -- Stephen Touset [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
[Mono-list] Design by Contract
I've been using C# for quite awhile now, but one feature that I wish was available in the language is support for Design by Contract: automatically-enforced preconditions and postconditions on functions, and invariants on classes. Having done some research into the problem, the best approach seems to be using attributes. Using statements inside functions works, but induces a lot of programmatic overhead; specifically, inheritance rules for DBC would need to be implemented manually. Invariants, also, would be tedious: code to check against the invariant would need to be added before the preconditions and after the postconditions of every function in the class. Worse still is that postconditions must be inserted above every return statement. This isn't too bad if you insist upon only one return statement per function, but for anyone with multiple returns, this becomes tedious quickly. And of course, all of these are clear violations of the Don't Repeat Yourself rule. Attributes seem to be the way to go. The pre/postconditions and invariants are, at the core, metadata about the functions and class. The attributes themselves would be able to understand their own inheritance criteria, and code can automatically be generated to verify the terms of the contract wherever needed. Unfortunately, the way attributes in C# are implemented, there seems to be no way to practically use them. Reflection may be powerful, but there doesn't appear to be a way that an attribute can access (or even determine) the function or class that it applies to. My initial approach was to use the CodeDom libraries to insert code into functions that would be dynamically based upon the applicable attributes, and enforce the conditions correctly. However, the inability for attributes to access the calling class all but cripples this attempt. My next thought was to simply have a script which would understand the attributes and insert the applicable statements at compile-time. However, the need for attribute inheritance quickly caused this approach to become unwieldy. Does anyone have an idea about how this could be done in a reasonable fashion? If so, would anyone be willing to help on the project? -- Stephen Touset [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Not all types imported from linked assemblies
For posterity, I've solved the problem. It was quite simple after all: I
forgot to put the public modifier on the class, so it was not
accessible from outside the assembly. Silly, silly, silly me.
On Tue, 2004-11-09 at 16:15 -0500, Stephen Touset wrote:
I've run into a bit of a problem trying to use the mcs compiler. I'm using
MonoDevelop as my IDE, but I've attempted to do the same steps through the
command line, both to no fruition.
Essentially, I have two projects: one as a main development project, the
other as a side project used for compiling unit tests and running them
(based off the NUnit assembly) and running them. Obviously, I need to link
in the classes from the base .NET project in order to run the unit tests
against them. MonoDevelop's way of doing this is to depend on the base
project, then run:
mcs -target:library -out:outfile.dll ${SOURCES} -r:${BASE_PROJECT_EXE}
-r:${OTHER_ASSEMBLIES}
Since this links against the base project's .exe, this makes classes from
the base project visible to the unit testing library. However, I right now
have two classes in the base project that I want to test, and the above
command only works for one of them. I've isolated them to clarify my
point.
$ mcs -target:library -out:test.dll -r ../LADR.exe -r
nunit.framework.dll Sources/Record/Record_Test.cs
Compilation succeeded
$
$ mcs -target:library -out:test.dll -r ../LADR.exe -r
nunit.framework.dll Sources/Record/LdapRecordProxy_Test.cs
Sources/Record/LdapRecordProxy_Test.cs(6) error CS0246: Cannot find type
`LdapRecordProxy'
Compilation failed: 1 error(s), 0 warnings
$
However, a quick strings shows that the assembly has both classes in place:
$ strings ../LADR.exe | grep Record
IRecord
LdapRecordProxy
Record
$
I could always include the sources from the base project by hand, but that
defeats MonoDevelop's nice project integration. Also, I'm sure I'm just
doing something obvious wrong, since one of the classes is being found
easily, but the other is not. Does anyone have a possible solution?
--
Stephen Touset [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
[Mono-list] Not all types imported from linked assemblies
I've run into a bit of a problem trying to use the mcs compiler. I'm using
MonoDevelop as my IDE, but I've attempted to do the same steps through the
command line, both to no fruition.
Essentially, I have two projects: one as a main development project, the
other as a side project used for compiling unit tests and running them
(based off the NUnit assembly) and running them. Obviously, I need to link
in the classes from the base .NET project in order to run the unit tests
against them. MonoDevelop's way of doing this is to depend on the base
project, then run:
mcs -target:library -out:outfile.dll ${SOURCES} -r:${BASE_PROJECT_EXE}
-r:${OTHER_ASSEMBLIES}
Since this links against the base project's .exe, this makes classes from
the base project visible to the unit testing library. However, I right now
have two classes in the base project that I want to test, and the above
command only works for one of them. I've isolated them to clarify my
point.
$ mcs -target:library -out:test.dll -r ../LADR.exe -r
nunit.framework.dll Sources/Record/Record_Test.cs
Compilation succeeded
$
$ mcs -target:library -out:test.dll -r ../LADR.exe -r
nunit.framework.dll Sources/Record/LdapRecordProxy_Test.cs
Sources/Record/LdapRecordProxy_Test.cs(6) error CS0246: Cannot find type
`LdapRecordProxy'
Compilation failed: 1 error(s), 0 warnings
$
However, a quick strings shows that the assembly has both classes in place:
$ strings ../LADR.exe | grep Record
IRecord
LdapRecordProxy
Record
$
I could always include the sources from the base project by hand, but that
defeats MonoDevelop's nice project integration. Also, I'm sure I'm just
doing something obvious wrong, since one of the classes is being found
easily, but the other is not. Does anyone have a possible solution?
--
Stephen Touset [EMAIL PROTECTED]
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Newbie question: GUI choice
I'm considering Mono as the environment for a cross-platform GUI application I'm designing. The app would ideally run with just one code base on Linux, OS X, and Windows. Is Windows.Forms the best choice for cross-platform GUI programming in Mono? I assume that Gtk# is Linux-specific, and Qt# looks like its going nowhere. GTK# is cross-platform, but has lots of DLLs etc. you have to deploy with it I think mono does implement WinForms more or less so you'd better use that I don't think using Windows.Forms will work. Unless I am wrong, mono is the only (or the only major) .NET-compatible CLI for the PowerPC platform. However, mono implements Windows.Forms through winelib, which is entirely dependent upon the x86 platform. Thus, Windows.Forms code is not portable to PowerPC through mono. However, there may be another PowerPC CLI out there that can handle Windows.Forms. If not, Gtk# will be your best bet, since it is cross-platform compatible as long as the GTK library is installed. However, be careful to avoid Gnome#, since that library is entirely dependent upon the GNOME desktop environment. -- Stephen Touset [EMAIL PROTECTED] ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Newbie question: GUI choice
The current, ongoing implementation of System.Windows.Forms is built directly on top of libgdiplus, which is our implementation of GDIPLUS.DLL using Cairo (http://www.cairographics.org). We have stopped developing the Wine-based Windows Form implementation for more than 6 months. I had not heard of this, but it is useful information. Nonetheless, I believe my point still has some merit. From what I understand through some quick skimming of recent Mono developments is that this libgdiplus implementation is far from complete, and missing implementations for crucial windowing elements. As it stands, I still think it would be better to build cross-platform applications using Gtk# at this time, since Gtk# is fully (or almost-fully) implemented in mono. No offense is meant towards Ximian's excellent development efforts, but I feel that if the OP is intending to develop a product for commercial release, they can't rely on the new Windows.Forms implementation until it has been released, or is at least nearing completion. -- Stephen Touset [EMAIL PROTECTED] ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Newbie question: GUI choice
That would be perfect if in the future Windows.Form would use Qt# under kde and Gtk# under Gnome. As I understand it, this is probably not likely to happen any time in the near future. The Qt and Gtk APIs not only differ by their function calls, but their basic architecture, too. It would be an extremely difficult endeavor to create an API that fully-exposed the features in different windowing system architectures. -- Stephen Touset [EMAIL PROTECTED] ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
