|
hi
how i can make a stand alone c# windows application?
i want to use it somewhere without installing .NET frameworw.
thanks
|
|
|
|
|
ABBASI_RA wrote:
how i can make a stand alone c# windows application?
i want to use it somewhere without installing .NET frameworw.
Write it in C++. That's your only option. And don't use managed C++, or you'll need the .NET framework all over again
The reason everyone ships their .NET apps with a dependancy to the .NET framework is because that's the way it works. Your compiled C# program is not recognisable to any computer, the .NET framework is needed to compile it into a final executable.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
But, why can't Microsoft provide an option to prepare a stand-alone executable file in .NET for C# etc.?
Let there be an option for those who want managed code and dependency on .NET framework.
But let there also be an option for those developers who want their .NET application to be converted into stand-alone executable, may be at the cost of tying it with a particular operating system or processor-family. It is also possible for Microsoft to allow creation of stand-alone code for a particular OS (such as WIN XP) or a group of OS's. Later on the OS can have some mechanism to cater to different types of processor-family. In the olden days, in C compilers, there used to be an option at the time of compiling to "optimise" for a particular processor-family. Why can't Microsoft come up with some innovative idea?
At least, there could be something in the installation / setup program, which could convert the .NET executable to the stand-alone executable for that particular machine using utility such as ngen.exe . But, in such a case, the .NET IL (or MSIL) file containing all information about the coding should not be installed. Can there be a mechanism like this? Or, can Microsoft innovate such a mechanism which should not be difficult to imlement in .NET version 2.0?
If Microsoft wants a "transparent" code for other developers, why can't it make its own windows "core" code public?
|
|
|
|
|
Anonymous wrote:
But, why can't Microsoft provide an option to prepare a stand-alone executable file in .NET for C# etc.?
Because the whole POINT of .NET is the virtual machine, which can in theory be ported to other platforms. Even within Windows, this means that versions of the framework can be written to optimise code for specific processors.
Anonymous wrote:
Why can't Microsoft come up with some innovative idea?
They did. It's visual C++. What you're suggesting is a whole lot of work to give us what we already have. Being able to write to a common intermediate language so that we can mix and match languages is more of an evolution than a revolution, but it's still a decent idea IMO. If you don't like it, don't use managed languages.
Anonymous wrote:
Or, can Microsoft innovate such a mechanism which should not be difficult to imlement in .NET version 2.0?
Given that 2.0 is in final beta, even if this was an idea they were likely to take up, it would not be in 2.0.
The MSIL compiler does NOT create an executable in memory, it creates functions, one at a time. However, just like you need MFC as a DLL to run MFC apps ( unless you accept bloat in executable size ), even the compiled .NET executable is bound to call .NET libraries - why would they compile the code to manage regular expressions ( for example ) into every app instead of having them in a library ? So the size of the download might drop, but it would still exist.
Anonymous wrote:
If Microsoft wants a "transparent" code for other developers, why can't it make its own windows "core" code public?
What on earth do you mean ? Are you saying that your issue is that MSIL can be decompiled ? In fact, it can, and that applies to Microsoft's .NET code also. How does that mean they should give away all their code ? Should Coke be forced to give us their recipe ? What's the difference ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
They did. It's visual C++. What you're suggesting is a whole lot of work to give us what we already have. Being able to write to a common intermediate language so that we can mix and match languages is more of an evolution than a revolution, but it's still a decent idea IMO. If you don't like it, don't use managed languages.
In fact, what I was suggesting was that you have the best of both worlds as an option, i.e., the ease of C# and the advantage of stand-alone executable.
In any case, the main problem with managed code is that its MSIL code is so transparent that everything (including some portions of code such as licensing of trial version, encryption keys, etc.) can easily be seen by utilities like ILDASM and Lutz Roeder's Reflector. This problem is not so much with VC++, but then it is a difficult language comparatively. For a small developer for shareware etc., it matters a lot, though it may not matter for a big developer like you with Microsoft MVP status. So, it is a question of combining ease with features (i.e., some features at least as an option).
One should look at sharewares. How many sharewares are written in C# inspite of its ease? You will hardly find many. This is so inspite of the fact that C# is now existing for last 4 to 5 years. So, is it not that something is holding back C# from certain fields at least? I think C# is more useful for intra-company utilities and the like. If you want to launch a utility to the outside world, then you should be ready for an open-source treat for your C# application.
Christian Graus wrote:
What on earth do you mean ? Are you saying that your issue is that MSIL can be decompiled ? In fact, it can, and that applies to Microsoft's .NET code also. How does that mean they should give away all their code ? Should Coke be forced to give us their recipe ? What's the difference ?
I Don't believe in Microsoft bashing. Let them keep their code secret. But, don't you think that MSIL is slightly over-transparent, it does not permit you to conceal even a few secrets such as some important logic like licensing etc. The question is not whether MSIL can be decompiled, but whether it reveals all secrets. If it reveals all secrets, then sometimes decompiling may not even be necessary.
|
|
|
|
|
Anonymous wrote:
In fact, what I was suggesting was that you have the best of both worlds as an option, i.e., the ease of C# and the advantage of stand-alone executable.
Yeah, I get what you meant. However, as Nish said, you'd still need the framework, and you'd lose other advantages. Simply, it's not what .NET is for.
Anonymous wrote:
but then it is a difficult language comparatively.
Perhaps, but if this was easy, there'd be no money in it. That's MY problem with .NET
Anonymous wrote:
a big developer like you with Microsoft MVP status.
LOL - being an MVP doesn't actually mean anything about the sort of development I do. As it happens, I work for a fair sized company, but I do a lot of work on my own as well. And I would agree with you that security of code is an issue, especially for trial versions, etc. However, if I wrote a trial version of anything, it would be missing major pieces of functionality, and I would not ship that code. Even C++ can be reverse engineered, and every protection will get cracked.
Anonymous wrote:
So, is it not that something is holding back C# from certain fields at least?
Perhaps. However, you're guessing what the reasons are, you could be wrong.
Anonymous wrote:
I think C# is more useful for intra-company utilities and the like. If you want to launch a utility to the outside world, then you should be ready for an open-source treat for your C# application.
Well, IMO, that's where most of the money is anyhow.
Anonymous wrote:
But, don't you think that MSIL is slightly over-transparent, it does not permit you to conceal even a few secrets such as some important logic like licensing etc.
Yes, I already agreed with you here. It's sadly a by product of how the framework works. I don't see any way around it for shareware type products, but I don't see that tiny market sector as a driving force for Microsoft to add something that is fundamentally useless to most people - the end exe will still need the .NET framework, and advantages of the framework are lost.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Even if there was a C# native code compiler, it'd be pretty useless since you wouldn't be able to use the .NET f/w classes, as that'd require the .NET f/w to be on the target machine.
|
|
|
|
|
Yeah, that was my point also....
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hello,
What I am trying to do is to add some radio buttons to a GroupBox dynamically. The number of radio buttons to add is differnet from time to time so I used a foreach loop to add the buttons to the GroupBox. But unfortunately, the GroupBox displays nothing apart from its border. Here is the unworking code:
GroupBox choiceGroupBox = new GroupBox();<br />
int buttonY = 0;<br />
choiceGroupBox.SuspendLayout();<br />
<br />
foreach(Object choice in choices)
{<br />
RadioButton button = new RadioButton(); <br />
button.Text = (string)choice;<br />
button.Location = new Point(16,buttonY);<br />
choiceGroupBox.Controls.Add(button);<br />
buttonY += 5;<br />
} <br />
choiceGroupBox.ResumeLayout();
I don't see anything wrong with this code but the GroupBox simply displays nothing......
This problem seems only happens when the radio buttons are created on the fly since I've tried to add a single radio button to the GroupBox and GroupBox works perfectly.
Could any one point me to something working? I am really getting mad with this "small" problem .......
Thanks in advance!
|
|
|
|
|
Maybe Choices is null ?
Be sure that those conreols are visible, Try first to put them on any panel .
|
|
|
|
|
really thanks for your reply LongHC. choices was null.
|
|
|
|
|
|
Really ? I thought that maybe Visible needs to be explicity set, but I thought 'surely not' ? Enough so that I didn't even bother testing to see.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
Really ? I thought that maybe Visible needs to be explicity set, but I thought 'surely not' ? Enough so that I didn't even bother testing to see.
I recently had a similar problem. The problem is that the controls are being added after the Form's Show() method is called.
Though, I'll go back and check just to make sure this is the problem.
Marc
My website
Latest Articles:
Undo/Redo Buffer
Memento Design Pattern
|
|
|
|
|
I'm not doubting you, just doubting the sanity of the behaviour.
I guess it allows you to add controls for showing later, without them ever flashing onto the screen, although setting visible to false before adding them to the controls collection would achieve that also.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hey!
I am using System.IO.SerialPort in framework 2.0(Beta2) to listening on the port. I am also using DataReceived event on the serialPort object.
I have set the threshold to 1, this means that the event(DataReceived) will fired as soon as 1 byte is written to the serialport.
When this event is triggerd, I am using a ThreadPool to queue work to my OnRecivedData() method.
In OnRecivedData() I first reads existing on the serialport, but I also writes this icoming data to file.
To see if this realy got what it takes I have made som test. I am sending data as fast as posible over the nullmodem cable with the follwing port settings:
Baud: 11 5200
Data: 8
Parity: None
Stop; 1
Problem:
I have compared the file that I send, and the file I recived(creates) and this works fine in low speeds, but whenI am pushing the system to 100% load my program by moving around a window or something, It loses data?
I realy have to get a stable connection even during stress.
I first thought that I could set the ThreadPool to a higher priority, but I havent found any way to do this? It could also be the evnet(DataReceived) that is never fired, can I set higher priority on this event?
Best Regards
SnowJim
|
|
|
|
|
Your code for recieving data should itself be in a worker thread, so that it continues to function even when the UI thread is maxed out by you moving a window.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Yes, as I said, I use ThreadPool as soon as the event is triggerd.
Or do you mean that i need a separate thread for the event? I thought that when an event accure, then a new thread is automatly created to handle this event? or is it the main(GUI) thread that will be used to the event? And if so, is there any way to get an own thread to this?
BestRegards
SnowJim
|
|
|
|
|
It really shouldn't be losing data, under any circumstances. Did you view the file after closing the application? Maybe it was just getting buffered in memory?
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
Yes i know that there may be a buffert. But this buffert is flushed and writen to the file.
If i dont move the Window around so i get 100% CPU usage, the transfere works fine.
It is not losing data in the end, its on diffrent places al the time, and its often some lines of data(maby 5-6 that disipares?
But the Thread that runns the event? is this Thread, the same as the main thread(the thread that draws the GUI)?
Best Regards
SnowJim
|
|
|
|
|
Hmm. How are you running OnReceived? Are you using ThreadPool.QueueWorkItem or the BeginInvoke method on a delegate object? If so, your function is running on a separate thread, not the UI thread. However, if you are calling BeginInvoke on an object derived from Control (like Form, TreeView etc..) then the function will run on the main thread (UI thread).
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
Yes i am using the SerialPort.DataReceived Event.
I have done some more testing now!
In the DataReceived event funktioner(the funktion that the DataReceived envet will run) u placed the code that writes the data to the file, like this:
<br />
lock (this)<br />
{<br />
if (RUNNING)<br />
{<br />
RemovePortHandlerRAW.Write(serialPort.ReadExisting());<br />
RemovePortHandlerRAW.Flush();<br />
<br />
}<br />
}<br />
RUNNING will be true as long as i dont close the port.
I have tryed to changes the serialPort.ReceivedBytesThreshold to all between 1 and 512, but there is not much diffrenc.
If i dont move around some windows and dont get 100% CPU usage, the tranfere file is a perfect match to the one i sent. But if i move around the window so i get 100% CPU usage, then i will lose data in diffrent places?
It simes like that the event will not be fired as is would!?
I have thought of going back to a Thread that goes in a loop and check if there is somthing to read, and if, then it will read it, but this take some performance even if there is no data to be read.
Any sugestions?
BestRegards
SnowJim
PS hope you understand my english
|
|
|
|
|
Hey!
I have now runned some more tests!
I have made a Thread with priotity = normal, that runns in a loop as long as RUNNING == true, if serialPort.BytesToRead > 0, then it will read from the port and write it to file. If not, it will Thread.sleep(1).
This method is not working bether then the event method I dont realy know how to solve this problem, I must ensure that no data is lost in the transfare, no mather what.
Maby all programs will made mistakes when CPU usage is on 100%(when moving around(fast) for example a browser with alot of content)?
My program have not realy a GUI, its a "window control library"(homemade control), i am adding this dll(Window control library) to an other project with a form, with two buttsons(open/close). This means that there is no real time display of the incoming data(now adance GUI to redraw).
I am sending 100 000 rows that contains up to around 64 chars, when CPU usange is on 100% it misses rows, often up to 20-30 rows i have seen.
If you got any ide how to proccead, let me know!
Best Regards
SnowJim
|
|
|
|
|
Have you tried to create the System.IO.SerialPort in a thread of its own yet?
like this:
<code>
using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
using System.IO;
using System.IO.Ports;
namespace SerialTest
{
class SerialReceiver
{
private System.Threading.ManualResetEvent m_Closed = new System.Threading.ManualResetEvent(false);
private System.IO.Ports.SerialPort m_Port = null;
private Thread m_Thread = null;
public SerialReceiver()
{
this.m_Closed = new ManualResetEvent(false);
this.m_thread = new Thread(new ThreadStart(this.ThreadEntry));
this.m_thread.Start();
}
public ~SerialReceiver()
{
Close();
}
public void Close()
{
this.m_Closed.Set();
}
public void ThreadEntry()
{
this.m_Port = new System.IO.Ports.SerialPort("COM1");
this.m_Port.ReceivedBytesThreshold=1;
SerialDataReceivedEventHandler receivedHandler = new SerialDataReceivedEventHandler(Port_DataReceived);
this.m_Port.DataReceived += receivedHandler;
this.m_Port.Open();
this.m_Closed.WaitOne();
this.m_Port.OnDataReceived+= receivedHandler;
}
void Port_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
byte[] data = new byte[this.m_Port.BytesToRead];
this.m_Port.Read(data,this.m_Port.BytesToRead);
foreach(byte b in data)
{
}
}
}
}</code>
The code is not testet and a prototype (i do not have the 2.0 framework installed yet)
Btw. do you check if more than one byte is avail in your event handler? Even though the threshold for the event is 1 it is quite possible that there has more than one byte arived when the event is finally triggert.
/cadi
|
|
|
|
|
Thanks for your time!
You solution did unfortunately not solve this problem =(
I have thougt of that it maby is the serialPort that cant handle the stress. But i have tryed another serialPort program, and this program generates the exact same file, not data loses!
This most with other words have to do with my software, then if it is the MS serialport that cant handle the stress or if its me that makes any thing wrong is hard to tell.
Is there anyone else that could test this and comfirme the same problem?
Best Regards
SnowJim
|
|
|
|
|