vj#: I have an MSIL module which I would like to link into my VJ# project
but Visual Studio refuses to recognize it. The module is being
created by jbimp using the /t:module argument. If I use /t:library to
create a DLL instead Visual Studio will accept DLL. This works fine
but the DLL is a separate file and I want everything in one .EXE file.
Does anyone know how to make VJ# see a module? Also, am I correct in
assuming that a module will link in to make one EXE file?

I did not try this, but the assembly linker SDK tool (al.exe) could be worth
a small peek.


http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfAssemblyGenerationUtilityAlexe.asp


--
Regards,
Lars-Inge Tonnessen
http://emailme.larsinge.com
http://www.larsinge.com

Thanks, that was a great help. AL.exe allows me to build everything
batch style with no manual steps in Visual Studio. Nice! The only
problem is the result is still two files, a small EXE file containing
only the assembly manifest and the large module containing the MISL
code and resources (and no manifest). Is there any way of combining
these two files?

The /embed directive is for resources according to the docs. I tried
embeding the code anyway to see what would happen. The file grew
approprately larger but it could not find the entry point when run.

With client software one executable is aways better than two
interdependant files if you know what I mean. If something can go
wrong it will! Any help would be appreciated.

[quoted text, click to view]

I tried that first and it worked fine. Using the example above, it
finds MyClass.Main in the external file (t2.netmodule) just fine. It
does not work using /embed:t2.netmodule to embed the code. It seems
the /main directive only looks in the external module file for the

Mike,

As Lars pointed out you will need to use the Assembly Linker (AL)
command-line tool. VS.Net does not handle il modules only assemblies.

Thanks,

Michael Green
Microsoft Developer Support

[quoted text, click to view]

mmmmmmm.......

Did you try to specify the main option?

From the msdn docs:

/main:method
Specifies the fully-qualified name (class.method) of the method to use as an
entry point when converting a module to an executable file.

Example:
The following command creates an executable file t2a.exe with an assembly
from the t2.netmodule module. The entry point is the Main method in MyClass.

al t2.netmodule /target:exe /out:t2a.exe /main:MyClass.Main


--
Regards,
Lars-Inge Tonnessen
http://emailme.larsinge.com
http://www.larsinge.com

I came across this link which verifies my /main: suspicions:

http://www.msdnaa.net/Resources/Display.aspx?ResID=518

In this article he states "Al.exe's /main switch is not that useful
since it is unlikely that you'd ever create an assembly for an
application where the application's entry point isn't in the PE file
that contains the manifest metadata tables. I only mention the switch
here to make you aware of its existence."

[quoted text, click to view]

Yes, it does create a single file. It is a very small file containing only
the assembly manifest. It executes fine as long as the module is in the
same directory as the EXE file created by AL.exe. When I remove the module
it fails.

The /main: directive is to specify the entry point in the external module.
Read the Microsoft documentation at:

http://www.msdnaa.net/Resources/Display.aspx?ResID=518

It paints a picture that is quite different from my Java-centric view of
putting all your code and resources in one jar file to be sure you are
distributing everything the client needs. The new improved .NET world is
one where you group functionality into reusable modules accessible by other
assemblies, where users double-click on an application and .NET only
downloads the modules (files) not already local to your computer over the
net, where "dll hell" is gone, etc, etc. So my quest to get everything into
one file seems to boil down to "why would you want to do that"? It appears
to be an issue of "thinking in Java" vs. "thinking in .NET". Am I right?

Having said that, I STILL want to put everything in one file! Call me
old-fashion. So if you find a way please let me know.

Mike

Thankyou for confirming that. So you can no longer embed a library (dll or
MISL module) into your application to create a single file unless you have
the source code to that library. Not with Visual Studio. Not with a tool
such as AL.exe. It seems like a strange restriction but I guess I'll have
to live with it.

Mike

Mike,

AL should create a single file. Here is a command line that is dicussed in
the MSDN documentation:

al t2.netmodule /target:exe /out:t2a.exe /main:MyClass.Main

This creates a file called t2a.exe from t2.netmodule. To combine more than
one net module, just list them before any of the / switches.

I hope this is helpful.

Michael Green
Microsoft Developer Support

Mike,

I did some further research and the al.exe tool is designed to create multi
file assemblies and so it will not combine .netmodules. The /resource
switch is designed to allow you to embed resources, not code. So if you
need to have a single file assembly, you will need to put all of your code
in one source file. Alternatively you can create a DLL assembly and
distribute that with your EXE. To make keeping track of the DLL easier you
can strong name it and place it in the GAC (Global Assembly Cache), this
can be done as part of the installation process. Here is a link to a KB
article that explains how to install an assembly into the GAC:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;815808. When the
assembly is in the GAC, there isn't a need to worry about the dll becoming
lost.

I hope this information is helpful,

Michael Green
Microsoft Developer Support

Mike,

Visual Studio.Net only creates single file assemblies. Meaning that for
each project you have one assembly will be generated. The IDE does not
deal with .NetModules at all, only source files. The AL.EXE command allows
you to create multi-file assemblies, i.e. assemblies that consist of more
than one file.

Thanks,

Michael Green
Microsoft Developer Support

I recompiled my library as a .NetModule for AL.exe when I could not make
Visual Studio embed it as a dll, but I solved the problem. It turns out
that Microsoft Research has a tool called ILMerge.

http://research.microsoft.com/~mbarnett/ilmerge.aspx

Using ILMerge.exe I merged my dll with my exe file, finally! Thanks for
your suggestions. Sorry for pressing so hard but the application I'm
writing is similar to setup.exe in that the user downloads it, uses it once
and throws it away. Two files for a this application was simply not an
option.

Mike

Hi Mike,

Hey, not a problem. I'm glad you found a tool that will do what you needed.
Thanks for letting me know, I hadn't even seen this tool before.

Mike Green
Microsoft Developer Support