I think a rebuild's going to be necessary. JAR files and .NET Assemblies are not really the same kind of thing. They happen to get used to solve similar problems, so there are some aspects they have in common, but the implementation approaches are quite different.
A JAR is basically a ZIP containing a bunch of files, including both .class files and other non-code stuff. So the process for constructing a JAR is essentially: 1) Compile .java source code into .class files 2) Zip .class files and other stuff into a .jar But in .NET there is no equivalent to a .class file. You compile source code (and any non-code resources) directly into an assembly. So it looks like this: 1) Compile .cs/.vb/.whatever source code into an assembly, passing any non-code resources in to the compiler. In short, while in Java, the 'compile' and 'package' steps are separate, in .NET they form a single step. So if you want to change something in the assembly, that means building a new assembly, and that means compiling any code for that assembly. The only exception to this is if you build a multi-module assembly. You can split a single assembly across multiple files. It's a somewhat obscure thing to do, and you rarely need to do it in practice. But if you are in this situation, you don't necessarily need to rebuild. Technically, all you need to do is rebuild whichever module changed, and also rebuild the module containing the assembly manifest - everything else can remain untouched. However, in normal .NET build processes, there is only one module, so the module that changed is the same as the module that contains the assembly manifest, is the same as the module that contains all your code. (As an implementation detail, there's nothing stopping a compiler performing some kind of optimization here. For example, your compiler could compile each individual source file into per-source-file binary files that it stores as part of its build output. So it wouldn't actually need to recompile everything. So whether or not the recompilation really happens depends on the compiler. But that's just the implementation detail - all that really matters is: does the build take too long?..) -- Ian Griffiths - Pluralsight http://www.interact-sw.co.uk/iangblog/ -----Original Message----- From: Kunle Odutola > Not knowing anything about META.INF or MANIFEST.MF, or much > about Java, it's my impression that .Net "attributes" are the > place where some such things would be stored. Not > necessarily the ones that you show in your example, however. > > Info about the OS and the processor are not needed (as .Net > code is always in MSIL format); in theory (not sure about > practice) a .Net app built on 32-bit Windows (XP for example) > should run unchanged under Mono on 64-bit Linux. The custom info in my example was describing native code libraries required/used by a bundle/assembly. [Bundle is approx== Assembly + custom information in manifest] > Attributes provide a class-based mechanism that allows you to > tag various code elements (assemblies, methods, parameters, > ...) with arbitrary info that's available at runtime. Custom attribute classes were my first option. I am worried the resulting system would be inflexible since changing a bundle's "Bundle-Category" attribute would now require a rebuild of the otherwise unchanged source code. Is there a way round this on the CLR? Another consideration is that some bundles have no exectuable code. Perhaps just resources. But the may still have the custom info in the manifest too. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
