473,394 Members | 1,174 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,394 software developers and data experts.

ILMerge...Why?

I have read several threads regarding using ILMerge to combine all your
dlls with your exe to create one single exe file....I don't get it.

Why would you ever want to do this?

Todd
Jul 20 '08 #1
28 3841
MC
"Todd Carnes" <to********@gmail.comwrote in message
news:g5**********@aioe.org...
>I have read several threads regarding using ILMerge to combine all your
dlls with your exe to create one single exe file....I don't get it.

Why would you ever want to do this?
To deliver your product as a single .exe file that does not need any other
files or installation procedure. These are called "no-install programs" and
are a very welcome development (or revival of an old idea).
Jul 20 '08 #2
Todd Carnes wrote:
I have read several threads regarding using ILMerge to combine all your
dlls with your exe to create one single exe file....I don't get it.

Why would you ever want to do this?
In most cases it is a bad idea, because you get multiple copies
of the code in DLL's which is against the fundamental idea of DLL's.

But it makes deployment slightly easier and in some cases that can
justify it.

Arne
Jul 20 '08 #3
Todd,
>
Why would you ever want to do this?
May I ask you this with a question.

Why would you never want to do this?

Cor
Jul 20 '08 #4
Cor Ligthert[MVP] wrote:
Todd,
>>
Why would you ever want to do this?
May I ask you this with a question.

Why would you never want to do this?

Cor
Because I think it defeats the whole purpose of using dlls to begin
with. It seems like a step backwards to me. If you are going to stuff
all your code into one monolithic file, you might as well return to
using DOS as well.

But what do I know? :)

I thought the whole idea of dll's, as well as so's on Linux systems, was
that they could be unloaded from memory when not in use and that more
than one program can use them, thus saving disk space and saving time &
money (because you don't have to re-invent the wheel every time you
write a new program). Surely, once you've used ILMerge to squash
everything into one file this is no longer true, correct?

Todd
Jul 20 '08 #5
MC wrote:
"Todd Carnes" <to********@gmail.comwrote in message
news:g5**********@aioe.org...
>I have read several threads regarding using ILMerge to combine all your
dlls with your exe to create one single exe file....I don't get it.

Why would you ever want to do this?

To deliver your product as a single .exe file that does not need any other
files or installation procedure. These are called "no-install programs" and
are a very welcome development (or revival of an old idea).

Maybe I'm just being thick-headed here, but why is this "a very welcome
development"?

The whole idea off dll's is to get away from this. With a dll, if you
issue a bug fix for the dll, you only have to fix the dll and every
program that uses the dll gets the benefit of the fix. If you merge the
dll with your program, your program will be tied to that version of the
dll and you'll have to recompile your program every time a dll is changed.

Granted, I can think of one situation where this "might" be advantageous
(running the program from a portable media like a USB flash drive), but
I can think of several situations where this might be considered a bad idea.

Please understand, I am NOT trying to start an argument with this
question. I really don't see the benefit and am trying to understand.

Todd

Jul 20 '08 #6
Todd Carnes wrote:
MC wrote:
>"Todd Carnes" <to********@gmail.comwrote in message
news:g5**********@aioe.org...
>>I have read several threads regarding using ILMerge to combine all
your dlls with your exe to create one single exe file....I don't get it.

Why would you ever want to do this?

To deliver your product as a single .exe file that does not need any
other files or installation procedure. These are called "no-install
programs" and are a very welcome development (or revival of an old idea).

Maybe I'm just being thick-headed here, but why is this "a very welcome
development"?

The whole idea off dll's is to get away from this. With a dll, if you
issue a bug fix for the dll, you only have to fix the dll and every
program that uses the dll gets the benefit of the fix. If you merge the
dll with your program, your program will be tied to that version of the
dll and you'll have to recompile your program every time a dll is changed.

Granted, I can think of one situation where this "might" be advantageous
(running the program from a portable media like a USB flash drive), but
I can think of several situations where this might be considered a bad
idea.
Sometimes ease of deployment is the biggest priority.

Arne
Jul 20 '08 #7
In article <g5**********@aioe.org>,
Todd Carnes <to********@gmail.comwrote:
Cor Ligthert[MVP] wrote:
Todd,
>
Why would you ever want to do this?
May I ask you this with a question.

Why would you never want to do this?

Cor

Because I think it defeats the whole purpose of using dlls to begin
with. It seems like a step backwards to me. If you are going to stuff
all your code into one monolithic file, you might as well return to
using DOS as well.
It's not a step backwards because dll's weren't a step forward -- they
were a solution to a problem that almost was....
But what do I know? :)

I thought the whole idea of dll's, as well as so's on Linux systems, was
that they could be unloaded from memory when not in use and that more
than one program can use them, thus saving disk space and saving time &
money (because you don't have to re-invent the wheel every time you
write a new program). Surely, once you've used ILMerge to squash
everything into one file this is no longer true, correct?
You don't need DLL's to unload the code out of memory, and hard disk
space hasn't been an issue for anybody (including MS) since gigabyte
hard drives came out.

Back in the late 80's code size for major applications briefly
outstripped the available disk size when installed on on slightly older
systems. But in the last 20 years it's been the rare developer that
needed more hard drive space than was available on the average users
system. Today it's practically impossible to even get a user to think
about it.

Code reuse is a different matter, and in a way it's the saving grace of
DLLs. They limped along for a decade looking for a problem to solve,
one eventually came along -- the internet and interactive web page.

But unless you're working on a program that is going to have a web
based front end, or needs some other kind of distributed execution,
dlls just aren't of much benefit.

--
J.B. Moreno
Jul 21 '08 #8
J.B. Moreno,

As I would have written almost the same as you, I just want to add one word
near my opinion,
dlls just aren't of much benefit
anymore.

:-)

Cor
Jul 21 '08 #9
Dynamic loading is still a big benefit for plugin type systems.
Jul 21 '08 #10
J.B. Moreno wrote:
You don't need DLL's to unload the code out of memory, and hard disk
space hasn't been an issue for anybody (including MS) since gigabyte
hard drives came out.
I do see your point about the disk space, but just because you have
gigabytes of space available, doesn't mean you should use gigabytes of
space. :)

Also, although I can already hear the objections that will be raised on
this point, size DOES matter to those who want to download a program,
but are not fortunate enough to have access to super-fast internet
connections. Believe it or not there are still plenty of people out
there who are forced to either use a dial-up connection or not have
internet at all....

I know this because until recently I was one of those people who still
only had a 28k (not even 56k) dial-up connection because that was all
that was available where I lived. (LOL... Thank goodness, I moved.)

[snip]
Code reuse is a different matter, and in a way it's the saving grace of
DLLs. They limped along for a decade looking for a problem to solve,
one eventually came along -- the internet and interactive web page.

But unless you're working on a program that is going to have a web
based front end, or needs some other kind of distributed execution,
dlls just aren't of much benefit.
I don't work on programs with web-based front-ends, but I still use dlls
for code reuse. Why would I want to write the same code over and over
again when I can just write it once, store it in a dll and then use it
with as many programs as I want?

Todd

P.S. Thanks to everyone participating in this thread. I'm learning a
lot. (even if it might not seem like it at times <grin>)
Jul 22 '08 #11
Arne Vajhøj wrote:
Todd Carnes wrote:
>I have read several threads regarding using ILMerge to combine all
your dlls with your exe to create one single exe file....I don't get it.

Why would you ever want to do this?

In most cases it is a bad idea, because you get multiple copies
of the code in DLL's which is against the fundamental idea of DLL's.

But it makes deployment slightly easier and in some cases that can
justify it.
May I ask you for an example when it would be justified?

Todd

Jul 22 '08 #12
Todd Carnes <to********@gmail.comwrote:
J.B. Moreno wrote:
You don't need DLL's to unload the code out of memory, and hard disk
space hasn't been an issue for anybody (including MS) since gigabyte
hard drives came out.

I do see your point about the disk space, but just because you have
gigabytes of space available, doesn't mean you should use gigabytes of
space. :)
No, of course not...but are you building an application that requires
gigabytes of space?
Also, although I can already hear the objections that will be raised on
this point, size DOES matter to those who want to download a program,
but are not fortunate enough to have access to super-fast internet
connections. Believe it or not there are still plenty of people out
there who are forced to either use a dial-up connection or not have
internet at all....

I know this because until recently I was one of those people who still
only had a 28k (not even 56k) dial-up connection because that was all
that was available where I lived. (LOL... Thank goodness, I moved.)
Well, until fairly recently I didn't even see 28k (19-24 was the norm),
so I do understand....but in most cases DLL's won't make a difference.

2 out of 3 things have to be true for DLL'S to matter in regards to
size, 1 I'll take as a given (lack of access to a decent patcher
program), but the other two....

2. Frequent updates to PART of the program
3. Multiple programs installed on the users computer that share a
large amount of code.

DLL's don't help with the initial download, only subsequent downloads
and d
[snip]
Code reuse is a different matter, and in a way it's the saving grace of
DLLs. They limped along for a decade looking for a problem to solve,
one eventually came along -- the internet and interactive web page.

But unless you're working on a program that is going to have a web
based front end, or needs some other kind of distributed execution,
dlls just aren't of much benefit.

I don't work on programs with web-based front-ends, but I still use dlls
for code reuse. Why would I want to write the same code over and over
again when I can just write it once, store it in a dll and then use it
with as many programs as I want?
You can statically link against the same code -- dynamic linking is
useful when the code you're "reusing" changes faster than the code
using it (this is the case for plug-in's for instance), or is outside
your control.

Don't get me wrong, I'm not saying that they are never appropriate and
wouldn't necessarily recommend using ILMerge. But I would recommend
taking a look at your proposed usage before breaking things out into
separate DLL's.

--
J.B. Moreno
Jul 22 '08 #13
J.B. Moreno wrote:
Todd Carnes <to********@gmail.comwrote:
>J.B. Moreno wrote:
>>You don't need DLL's to unload the code out of memory, and hard disk
space hasn't been an issue for anybody (including MS) since gigabyte
hard drives came out.
I do see your point about the disk space, but just because you have
gigabytes of space available, doesn't mean you should use gigabytes of
space. :)

No, of course not...but are you building an application that requires
gigabytes of space?
LOL, no, of course I'm not. I was exaggerating a bit to make a point. :)
>Also, although I can already hear the objections that will be raised on
this point, size DOES matter to those who want to download a program,
but are not fortunate enough to have access to super-fast internet
connections. Believe it or not there are still plenty of people out
there who are forced to either use a dial-up connection or not have
internet at all....

I know this because until recently I was one of those people who still
only had a 28k (not even 56k) dial-up connection because that was all
that was available where I lived. (LOL... Thank goodness, I moved.)

Well, until fairly recently I didn't even see 28k (19-24 was the norm),
so I do understand....but in most cases DLL's won't make a difference.

2 out of 3 things have to be true for DLL'S to matter in regards to
size, 1 I'll take as a given (lack of access to a decent patcher
program), but the other two....

2. Frequent updates to PART of the program
3. Multiple programs installed on the users computer that share a
large amount of code.

DLL's don't help with the initial download, only subsequent downloads
and d
You know, I hadn't looked at it in that way before. you make a good point.

Thanks for taking the time to respond. :)

Todd

Jul 22 '08 #14
Todd Carnes wrote:
I thought the whole idea of dll's, as well as so's on Linux systems, was
that they could be unloaded from memory when not in use and that more
than one program can use them, thus saving disk space and saving time &
money (because you don't have to re-invent the wheel every time you
write a new program). Surely, once you've used ILMerge to squash
everything into one file this is no longer true, correct?
A couple of things. One, only AppDomains can be unloaded. Therefore,
statically linked assemblies can not be unloaded.
Two, there is an overhead for loading assemblies. Perhaps nothing
noticeable for a handful of assemblies, but if you're breaking
everything out in 10's or 100's of assemblies, your load time of the
application will increase significantly. By ILMerge'ing them into a
single EXE you can reduce this overhead.

--
Joel Lucsy
"The dinosaurs became extinct because they didn't have a space program."
-- Larry Niven
Jul 23 '08 #15
Todd Carnes wrote:
Arne Vajhøj wrote:
>Todd Carnes wrote:
>>I have read several threads regarding using ILMerge to combine all
your dlls with your exe to create one single exe file....I don't get it.

Why would you ever want to do this?

In most cases it is a bad idea, because you get multiple copies
of the code in DLL's which is against the fundamental idea of DLL's.

But it makes deployment slightly easier and in some cases that can
justify it.

May I ask you for an example when it would be justified?
The obvious one is if for whatever reasons requirements:
- must be distributable as a single file
- must run as is without any installation
- must be a windows app not a web app
have been cast in stone.

Arne
Jul 28 '08 #16
J.B. Moreno wrote:
Code reuse is a different matter, and in a way it's the saving grace of
DLLs. They limped along for a decade looking for a problem to solve,
one eventually came along -- the internet and interactive web page.

But unless you're working on a program that is going to have a web
based front end, or needs some other kind of distributed execution,
dlls just aren't of much benefit.
What ??

Modularization of the deployment model is essential for
a decent development process.

Building everything to a big EXE does not work at all
for large projects.

I would be skeptical about it working even for medium
size projects.

Arne
Jul 28 '08 #17
Arne Vajhj <ar**@vajhoej.dkwrote:
J.B. Moreno wrote:
Code reuse is a different matter, and in a way it's the saving grace of
DLLs. They limped along for a decade looking for a problem to solve,
one eventually came along -- the internet and interactive web page.

But unless you're working on a program that is going to have a web
based front end, or needs some other kind of distributed execution,
dlls just aren't of much benefit.

What ??

Modularization of the deployment model is essential for
a decent development process.
Deployment is part of the development process, but in most cases it
shouldn't be driving it. If it is, then you probably have some kind of
distributed execution system, and not a single application.

Building everything to a big EXE does not work at all
for large projects.
How does it not work? And how about putting some numbers to "large"
and "medium"?
I would be skeptical about it working even for medium
size projects.
It sounds like you're talking systems, in which case yeah sure, you
don't want to take down part of the system because you're updating
another. But that's covered under distributed execution -- one
user/one app works just fine when distributed as a single unit.

--
J.B. Moreno
Jul 28 '08 #18
On Jul 20, 10:37*am, Todd Carnes <toddcar...@gmail.comwrote:
The whole idea off dll's is to get away from this. With a dll, if you
issue a bug fix for the dll, you only have to fix the dll and every
program that uses the dll gets the benefit of the fix. If you merge the
dll with your program, your program will be tied to that version of the
dll and you'll have to recompile your program every time a dll is changed..
There is a counter argument to that. The bug fix might actually break
your application if your were relying on the behavior that the bug was
causing. That's one (among many) reasons for testing your application
if anything changes including its dependencies. I'm not saying this
argument outweighs the benefits of using dlls though.
Jul 28 '08 #19
On Jul 20, 5:58*am, "Cor Ligthert[MVP]" <notmyfirstn...@planet.nl>
wrote:
Why would you never want to do this?
I think using ILMerge requires more justification than not using it.
Modularity, memory management, disk useage, and application
maintenance represent a handful of benefits for using dlls that I
could come up with off the top of head. Though, I can also think of
scenarios where ILMerge would be useful.
Jul 28 '08 #20
MC
The whole idea off dll's is to get away from this. With a dll, if you
issue a bug fix for the dll, you only have to fix the dll and every
program that uses the dll gets the benefit of the fix. If you merge the
dll with your program, your program will be tied to that version of the
dll and you'll have to recompile your program every time a dll is changed.
..There is a counter argument to that. The bug fix might actually break
..your application if your were relying on the behavior that the bug was
..causing. That's one (among many) reasons for testing your application
..if anything changes including its dependencies. I'm not saying this
..argument outweighs the benefits of using dlls though.

I think it does. Things like this have happened many times. Programmers
experiment to find out what a library function actually does -- if it
doesn't match its documentation -- and they use it the way that actually
works. Later, somebody changes it so it matches its documentation, instead
of changing the documentation to match what was actually implemented, and
the application breaks.
Jul 28 '08 #21
J.B. Moreno wrote:
Arne Vajhj <ar**@vajhoej.dkwrote:
>J.B. Moreno wrote:
>>Code reuse is a different matter, and in a way it's the saving grace of
DLLs. They limped along for a decade looking for a problem to solve,
one eventually came along -- the internet and interactive web page.

But unless you're working on a program that is going to have a web
based front end, or needs some other kind of distributed execution,
dlls just aren't of much benefit.
What ??

Modularization of the deployment model is essential for
a decent development process.

Deployment is part of the development process, but in most cases it
shouldn't be driving it. If it is, then you probably have some kind of
distributed execution system, and not a single application.
No.
>Building everything to a big EXE does not work at all
for large projects.

How does it not work?
The teams producing different parts of the app becomes dependent
on each other.
And how about putting some numbers to "large"
and "medium"?
Those terms are not that well defined.

But if you think:
large is 1 million LOC
medium 100000-1 million LOC
then you are not that far from me.
>I would be skeptical about it working even for medium
size projects.

It sounds like you're talking systems, in which case yeah sure, you
don't want to take down part of the system because you're updating
another. But that's covered under distributed execution -- one
user/one app works just fine when distributed as a single unit.
I am talking development process - not operations.

Arne
Aug 2 '08 #22
Arne Vajhj <ar**@vajhoej.dkwrote:
J.B. Moreno wrote:
Arne Vajhj <ar**@vajhoej.dkwrote:
-snip-
Modularization of the deployment model is essential for
a decent development process.
Deployment is part of the development process, but in most cases it
shouldn't be driving it. If it is, then you probably have some kind of
distributed execution system, and not a single application.

No.
Either a distributed system or frequent updates -- otherwise what does
it matter if they have to download X amount of data, unzip it it into Y
number of files or 1 file?

Building everything to a big EXE does not work at all
for large projects.
How does it not work?

The teams producing different parts of the app becomes dependent
on each other.
No more so than with static linking -- it adds an additional step, but
everything else is otherwise unchanged.

MSIs, ILMerge, VISE -- lots of tools to turn the deployment into a
single application, there's really no difference between having a
deployment application and having an application XCopy application
deployment.

The difference comes in when updating or extending it -- the initial
download is the same.
And how about putting some numbers to "large" and "medium"?

Those terms are not that well defined.

But if you think:
large is 1 million LOC
medium 100000-1 million LOC
then you are not that far from me.
So maybe 5-50 meg for a medium and, 50+ for a large.

On a fast connection, you don't even need to break it up into smaller
pieces for frequent updates. On a slow connection, you better hope you
don't have to do frequent updates because even portion is going to be
slow...

I would be skeptical about it working even for medium
size projects.
It sounds like you're talking systems, in which case yeah sure, you
don't want to take down part of the system because you're updating
another. But that's covered under distributed execution -- one
user/one app works just fine when distributed as a single unit.

I am talking development process - not operations.
Then you're mixing things up -- if you're not actually using the
dynamic loading (by which I mean switching to a newer version of the
code without relinking on the users machine) then it doesn't gain you
anything.

--
J.B. Moreno
Aug 3 '08 #23
On Jul 27, 10:14*pm, "J.B. Moreno" <pl...@newsreaders.comwrote:
Deployment is part of the development process, but in most cases it
shouldn't be driving it. *If it is, then you probably have some kind of
distributed execution system, and not a single application.
Building everything to a big EXE does not work at all
for large projects.

How does it not work? *And how about putting some numbers to "large"
and "medium"?
One thing to consider to here is that the CLR loader is very lazy. It
will only load what it needs. I can't say with absolute certainty,
but I suspect if everything were stuffed into one assembly then system
resources could be negatively affected. Assuming that is the case
then the conclusion is that the effect is proportional to the size of
the project.
Aug 4 '08 #24
On Aug 4, 8:39*am, Brian Gideon <briangid...@yahoo.comwrote:
On Jul 27, 10:14*pm, "J.B. Moreno" <pl...@newsreaders.comwrote:
Deployment is part of the development process, but in most cases it
shouldn't be driving it. *If it is, then you probably have some kind of
distributed execution system, and not a single application.
Building everything to a big EXE does not work at all
for large projects.
How does it not work? *And how about putting some numbers to "large"
and "medium"?

One thing to consider to here is that the CLR loader is very lazy. *It
will only load what it needs. *I can't say with absolute certainty,
but I suspect if everything were stuffed into one assembly then system
resources could be negatively affected. *Assuming that is the case
then the conclusion is that the effect is proportional to the size of
the project.
just to add to this thread. I am a big fan of ilmerge, in my case it
has nothing to do with dll's it has more to do with resource files. In
my case, I have to distribute couple of resource files created another
program (dynamically) need to be included in the final exe of one
another program. In this case, I would like to use ILMerge and it
works like a charm except the fact it has memory problems.
Aug 4 '08 #25
Brian Gideon <br*********@yahoo.comwrote:
On Jul 27, 10:14*pm, "J.B. Moreno" <pl...@newsreaders.comwrote:
Deployment is part of the development process, but in most cases it
shouldn't be driving it. *If it is, then you probably have some kind of
distributed execution system, and not a single application.
Building everything to a big EXE does not work at all
for large projects.
How does it not work? *And how about putting some numbers to "large"
and "medium"?

One thing to consider to here is that the CLR loader is very lazy. It
will only load what it needs. I can't say with absolute certainty,
but I suspect if everything were stuffed into one assembly then system
resources could be negatively affected. Assuming that is the case
then the conclusion is that the effect is proportional to the size of
the project.
That's possible, although extremely vague (and fallible) memory says
that even within the same file the assemblies are distinct and only
loaded as needed (and unloaded when not).

--
J.B. Moreno
Aug 6 '08 #26
On Aug 6, 6:32*am, "J.B. Moreno" <pl...@newsreaders.comwrote:
One thing to consider to here is that the CLR loader is very lazy. *It
will only load what it needs. *I can't say with absolute certainty,
but I suspect if everything were stuffed into one assembly then system
resources could be negatively affected. *Assuming that is the case
then the conclusion is that the effect is proportional to the size of
the project.

That's possible, although extremely vague (and fallible) memory says
that even within the same file the assemblies are distinct and only
loaded as needed (and unloaded when not).
I don't know either. I suppose I could actually use ILMerge and
examine the resultant assembly to make the determination, but that
takes time. Anyone know for sure?
Aug 6 '08 #27
Actually, load time may decrease by breaking things out to DLLs. .Net
only loads assemblies on demand, so until your program uses them, they
sit on the disk unloaded. If on the other hand you've merged your
DLLs into one file, the ENTIRE file must be read into memory before
execution can begin. So I don't think this argument is a particularly
sound one.

On Jul 22, 8:30*pm, Joel Lucsy <jjlu...@gmail.comwrote:
Two, there is an overhead for loading assemblies. Perhaps nothing
noticeable for a handful of assemblies, but if you're breaking
everything out in 10's or 100's of assemblies, your load time of the
application will increase significantly. By ILMerge'ing them into a
single EXE you can reduce this overhead.
Aug 6 '08 #28
Brian Gideon <br*********@yahoo.comwrote:
On Aug 6, 6:32*am, "J.B. Moreno" <pl...@newsreaders.comwrote:
One thing to consider to here is that the CLR loader is very lazy. *It
will only load what it needs. *I can't say with absolute certainty,
but I suspect if everything were stuffed into one assembly then system
resources could be negatively affected. *Assuming that is the case
then the conclusion is that the effect is proportional to the size of
the project.
That's possible, although extremely vague (and fallible) memory says
that even within the same file the assemblies are distinct and only
loaded as needed (and unloaded when not).

I don't know either. I suppose I could actually use ILMerge and
examine the resultant assembly to make the determination, but that
takes time. Anyone know for sure?
Well, not about ILMerge but whether assemblies are unloaded depends
upon whether they are loaded domain neutral or not...more later.

--
J.B. Moreno
Aug 7 '08 #29

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Tim Marsden | last post by:
Hi, I am trying to use ILMerge to consolidate a .exe and serval .dll's into a single .exe. (VB.NET) I am using the following command. ILMerge.exe /wildcards /log:Log.txt...
0
by: drewnoakes | last post by:
Hi, I'm using ILMerge to combine various assemblies. Everything works bar one problem... the 3rd party licensed components no longer see the embedded licensing information. According to...
0
by: BL | last post by:
Is there any way to merge assembly ('MyLib.dll') with declared LicenseProviderAttribute into winexe application? By now I'm getting "ILMerge.Merge: The assembly 'MyLib.dll' was not merged in...
1
by: Oz Sozen | last post by:
I want to use ILMerge in my project, but it requires a framework version that I cannot find the download for (2.0.7.... something). The latest I can see is 2.0.5. Does anybody know where I can find...
6
by: Antonio Palermo | last post by:
I don't know how to use "ILMerge", Can you help me? TIA Antonio Palermo Excuse me for my bad English, I'm italian
0
by: Dennis | last post by:
I am trying to use ILMerge to create a single executable. Below are the DOS command lines that I am using: cd c:\program files\ilmerge ilmerge /lib:c:\programming\vs-projects\recipes\bin...
3
by: JT | last post by:
Hi, I am having trouble finding information about GUIDs and strong-names and don't really know what I need. If that's too ambiguous, please tell me where to look for info on these. Here's...
0
vikramadith
by: vikramadith | last post by:
I'm having some issues merging dlls into my exe Basically I have three VS projects, one producing an exe, and the other two producing dlls. Let us just call it MyApp.exe, Lib1.dll and Lib2.dll....
1
by: kulabhishek | last post by:
Hi, I am using ILMerge tool to merge the all the dlls into one. In my case I do not want to include one dll into output one. But my other dlls are using the reference of that dll. How it can be...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.