By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,852 Members | 994 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,852 IT Pros & Developers. It's quick & easy.

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

P: n/a
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

--
Don't talk unless you can improve the silence.

Nov 29 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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" <ku***********@REMOVETHISokocha.freeserve.co.uk> wrote in
message news:ug****************@TK2MSFTNGP12.phx.gbl...
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

--
Don't talk unless you can improve the silence.

Nov 30 '05 #2

P: n/a
"Lloyd Dupont" <net.galador@ld> wrote in message
news:uV**************@TK2MSFTNGP15.phx.gbl...

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

--
Don't talk unless you can improve the silence.

Nov 30 '05 #3

P: n/a
>> 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
Dec 1 '05 #4

P: n/a

"Lloyd Dupont" <net.galador@ld> wrote in message
news:uR**************@TK2MSFTNGP12.phx.gbl...
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


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.
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.


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

Dec 2 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.