Are you on Windows trying to write cross-platform apps or on another OS wanting to use Windows tools? I'm not on Windows and don't advocate using Windows tools for anything except Windows development. Mono is a third-party project which supports .Net development on Unix-derived OSes (mainly Linux). Microsoft has a lousy track record supporting third-party projects. I can tell you how to create an icon on '98. It is possible to run VB.Net programs on computers which don't have VB.Net on them if they have some libraries.
Anything which is part of .Net is part of a Microsoft suite of tools which is intended for Windows only. Mono, which is linked to elsewhere, is a product of Miguel de Icaza, who may be described as one of those rare Open Source developers who is friendly to Microsoft (they have been relatively good to him). Microsoft chooses to provide Mono with enough to allow them to support .Net at this time. Be aware this may change in the future:
Among the firms I did office work for when I was going to college in the early 90's were several small firms which did engineering work. While they did not sell software, per se, they usually ran their systems on Unix (for tools like Oracle) and when they did coding used the GNU Compiler Collection (GCC). Recently a story appeared that Windows Vista restricts the size of memory available to executables compiled with GCC to 32 megabytes. When I mentioned this to an acquaintance who works at a nearbye University, he asked, Old Unix Guy he is, why would anyone want an executable that takes more than 32 megs? It didn't occur to him that firms such as I used to work for are more concerned with selling services than in selling "correct" software. His employer is trying to get everyone to write "correct" software so people will send more students. Most of these firms will get more customers if their software works rather than if it's correct.
My most recent computer purchase was an old second-hand Windows 98 laptop from an engineering firm. It came with an ethernet card and driver which -- in Windows mind, used GCC and its libraries to run it. It doesn't have Windows on it any more but it still has GCC.
I haven't used Windows extensively, and definitely not for development, since Win'98. I can tell you how to get an icon on your desktop in '98. Open the folder it's in, right-click on the program, and you should see a number of options. One of them is properties. Open that window and you will see a number of options you can change, including icons. Generally of course it will use a default executable icon. If you're happy with that, fine.
To get it on your desktop, go to the original right-click menu and select "Create Shortcut". A copy of the program will appear in the folder where the original is, and you can move it to your desktop. Read the documentation and play around with it.
Most compilers these days create code which uses dynamically linked libraries. They will link some machine code into the executable, but for efficiency's sake they will assume the machine has certain other libraries. You are, as the program's author, responsible for knowing what libraries (DLL's) your program links to, and where it looks for them. If you link them into your program, or otherwise distribute your code with them, then it should be no trouble to distribute your programs.
There is a very old phrase for something like this: RTFM. These days I spend most of my time on Linux. For me this includes switching between Gnome, KDE, XFCE4 and fluxbox desktops unpredictably. I'm constantly reading the documentation of it. I understand Windows does not always offer the best documentation for its products, but go ahead and read. One of the websites in my sources is from Microsoft.