What is the .NET equivalent of Java's MANIFEST.MF and co.?

[Kunle Odutola]

I'm trying to understand where the information in the META.INF directory
including MANIFEST.MF etc is to be found for .NET assemblies.

Also some projects such as Eclipse's OSGi kernel stores additional info in
the MANIFEST.MF file. What would be the .NET equivalent where such info can
be stored?

Kunle

 

[Lloyd Dupont]

what kind of info are you speaking about?

info about assembly author, etc....
are stored as attirbute like that:
===
[assembly: AssemblyTitle("NGui")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("")]
[assembly: AssemblyProduct("NGui")]
[assembly: AssemblyCopyright("Copyright © 2005")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]
===

there is no "classpath" info. assembly are either in the same directory,
path or GAC. as DLL should be.

signing is done with the compiler and a .snk file

 

[Kunle Odutola]

Hi Lloyd,

what kind of info are you speaking about?

Custom descriptive info mainly. It will be used by classes in my framework
when loading/managing bundles. In the OSGi specs, a bundle maps to an
assembly with custom info in it's equivalent of the Java MANIFEST.MF file.
Examples of the sort of custom info follows (sorry it's a bit long):

Bundle-Activator: com.acme.fw.Activator
The Bundle-Activator header specifies the name of the class used to start
and
stop the bundle.

Bundle-Category: osgi, test, nursery
The Bundle-Category header holds a comma-separated list of category
names.

Bundle-Classpath: /jar/http.jar,.
The Bundle-Classpath header defines a comma-separated list of JAR file path
names or directories (inside the bundle) containing classes and resources.

Bundle-Copyright: OSGi (c) 2002
The Bundle-Copyright header contains the copyright specification for this
bundle.

Bundle-DocURL: http:/www.acme.com/Firewall/doc
The Bundle-DocURL headers must contain a URL pointing to documentation
about this bundle.

Bundle-Localization: OSGI-INF/l10n/bundle
The Bundle-Location header contains the location in the bundle where
localization files can be found.

Bundle-NativeCode: /lib/http.DLL; osname = QNX; osversion = 3.1
The Bundle-NativeCode header contains a specification of native code
libraries contained in this bundle.

Bundle-RequiredExecutionEnvironment: CDC-1.0/Foundation-1.0
The Bundle-RequiredExecutionEnvironment contains a comma-separated
list of execution environments that must be present on the Service Platform.

DynamicImport-Package: com.acme.plugin.*
The DynamicImport-Package header contains a comma-separated list of
package names that should be dynamically imported when needed.

Export-Package: org.osgi.util.tracker;version=1.3
The Export-Package header contains a declaration of exported packages.

Fragment-Host: org.eclipse.swt; bundle-version="[3.0.0,4.0.0)"
The Fragment-Host header defines the host bundle for this fragment.

Import-Package: org.osgi.util.tracker,org.osgi.service.io;version=1.4
The Import-Package header declares the imported packages for this bundle.

Require-Bundle: com.acme.chess
The Require-Bundle header specifies the required exports from another
bundle.

info about assembly author, etc....
are stored as attirbute like that:
===
[assembly: AssemblyTitle("NGui")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("")]
[assembly: AssemblyProduct("NGui")]
[assembly: AssemblyCopyright("Copyright © 2005")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]
===

I initially thought of representing this information with custom attributes.
I didn't because I'm worried about losing flexibility because changing a
bundle's "Bundle-Category" attribute would now require a rebuild of the
otherwise unchanged bundle/assembly's source code. Is there a way round that
with the CLR model?


Kunle

 

[Lloyd Dupont]

what kind of info are you speaking about?

Custom descriptive info mainly. It will be used by classes in my framework
when loading/managing bundles. In the OSGi specs, a bundle maps to an
assembly with custom info in it's equivalent of the Java MANIFEST.MF file.
Examples of the sort of custom info follows (sorry it's a bit long):

Bundle-Activator: com.acme.fw.Activator

=> could be specified with the compiler

Bundle-Category: osgi, test, nursery
Bundle-RequiredExecutionEnvironment: CDC-1.0/Foundation-1.0
Import-Package: org.osgi.util.tracker,org.osgi.service.io;version=1.4
Require-Bundle: com.acme.chess

=> uh?

Bundle-Classpath: /jar/http.jar,.
Bundle-NativeCode: /lib/http.DLL; osname = QNX; osversion = 3.1

=> no equivalent, look in local directory, PATH & GAC

Bundle-Copyright: OSGi (c) 2002
Bundle-DocURL: http:/www.acme.com/Firewall/doc

=> use standart assembly attribute

DynamicImport-Package: com.acme.plugin.*
Fragment-Host: org.eclipse.swt; bundle-version="[3.0.0,4.0.0)"

=> use custom assembly attribute

Bundle-Localization: OSGI-INF/l10n/bundle

=> you should read the internationalization section, should be in sattelite
assembly in specific directories

Export-Package: org.osgi.util.tracker;version=1.3

=> use reflection on the assembly

I initially thought of representing this information with custom
attributes.
I didn't because I'm worried about losing flexibility because changing a
bundle's "Bundle-Category" attribute would now require a rebuild of the
otherwise unchanged bundle/assembly's source code. Is there a way round
that
with the CLR model?

No.
However if you don't use Visual Studio but some command line tool to build
your DLLs/EXEs,
you could make a multi-module assembly (CSC /t:module), all bundled together
with AL.
In which case you could have a module with a single C# source file with the
attributes.
You, then, just need to recompile this module and rebuilt the DLL/EXE with
all the modules.

It's certainly uselessly complicated but if you are worry about compiling
your source code, that's the way to go.

It has some advantages though.
For exemple this way you could embed native DLL inside your assembly.

Lloyd

 

[Kunle Odutola]

Custom descriptive info mainly. It will be used by classes in my framework
when loading/managing bundles. In the OSGi specs, a bundle maps to an
assembly with custom info in it's equivalent of the Java MANIFEST.MF file.
Examples of the sort of custom info follows (sorry it's a bit long):

Bundle-Activator: com.acme.fw.Activator

=> could be specified with the compiler

Bundle-Category: osgi, test, nursery
Bundle-RequiredExecutionEnvironment: CDC-1.0/Foundation-1.0
Import-Package: org.osgi.util.tracker,org.osgi.service.io;version=1.4
Require-Bundle: com.acme.chess

=> uh?

Bundle-Classpath: /jar/http.jar,.
Bundle-NativeCode: /lib/http.DLL; osname = QNX; osversion = 3.1

=> no equivalent, look in local directory, PATH & GAC

Bundle-Copyright: OSGi (c) 2002
Bundle-DocURL: http:/www.acme.com/Firewall/doc

=> use standart assembly attribute

DynamicImport-Package: com.acme.plugin.*
Fragment-Host: org.eclipse.swt; bundle-version="[3.0.0,4.0.0)"

=> use custom assembly attribute

Bundle-Localization: OSGI-INF/l10n/bundle

=> you should read the internationalization section, should be in sattelite
assembly in specific directories

Export-Package: org.osgi.util.tracker;version=1.3

=> use reflection on the assembly

Hmmm, perhaps I'm trying too hard to emulate Java's environment. Thanks, I'm
back in my .NET developer alter-ego now.
Yep, use of custom attributes, and perhaps the .config files plus standard
..NET localization should be applied to reach my goal.

No.

OK. Thanks. This jives with my initial thoughts and advice I've received
elsewhere.

It's certainly uselessly complicated but if you are worry about compiling
your source code, that's the way to go.

It has some advantages though.
For exemple this way you could embed native DLL inside your assembly.

Steady on chap!. I wasn't planning on going that far. ;-)

Kunle