Develop Reference

Throttling network for other applications

A friend likes to limit his applications to a use a certain bandwidth-limit. Seen as he doesn't have the widest connection and - for example - not every application that downloads/uploads has the ability to throttle/limit their downloads/uploads (Like Steam or a torrent downloader.). So he was wondering if I could maybe put something together since I fiddle around with WinForms often. I recommended NetLimiter and NetBalancer, but I was curious as to whether I could make this in C# myself.
I have searched the web and found some decent solutions as to throttling in an application itself but as to throttling applications outside of the current application you have the source code of, I haven't been able to find anything that would help me understand how to program this from scratch.
Do any of you know how I'd go about throttling other applications? Would I have to write my own network interface and have Windows reroute traffic through that?
Thank you for your time.
EDIT: Seen as the first comment tells me I'm at the wrong address with C#, I rephrased my question in the hopes of a better way to get an answer.

Working with PowerShell and modular GUI's?

One of my problems, is that I support clients who often spend a lot of time monitoring if their servers (and services) are functioning properly, and that their network is up and running smoothly.
All of these tasks are easily re mediated through PowerShell, and I had a grand idea to unify all of the tasks and present them in a GUI, with the ability to tail the logs on remote servers at will.
I can execute PowerShell remotely to ascertain all of the facts I need about the servers involved, can poll and retrieve all the relevant points of data, aggregate them in a database, perform trend and abnormality analysis, that's all good.
But I want to aggregate it all into a sort of "management console" to alleviate all of the mundane tasks. Why not?
So I'm looking for some pointers as to where I can look for any frameworks, HTML based or application based, that can leverage the power of PowerShell into a somewhat modular UI interface. From what I've seen and experimented with, C# is abnormally complicated when executing PowerShell cmdlets.
Pardon my ignorance, I'm mainly a scripter. Please point me to the right direction!
I can imagine the exact GUI I want, and can grab and analyze all the data I need to accomplish it... Just not sure of the glue that connects the two.

Take a look on PowerGUI by Dell - it's designed for tasks like this.
Also you can try to do all with bare-hands coding using Windows Forms in PowerShell, like described on this TechNet blog post's series.
Also there is many PowerShell IDE's with visual Form designers - AdminScript is one of oldest.

This is a very general question, I beleive too general for StackOverflow. Here are my first thoughts as is :
1) Collecting datas on server is avery old story, begining with SNMP and continuing with WMI and more generaly "Windows Management Framework" on Windows. So client UI, you can adapt to your clients exists on the market. Have a look to Centreon, or Paessler.
2) As far as PowerShell is involved have a look to the Quest (now DELL) PowerGUI console (not the script editor)
3) If really you want it (not a good idea for me) you can write a PowerShell UI application, have a look to Sapien's PowerShell Studio. I give some clues about programming PowerShell UIs here.

Launch program on server through web

OK, so I'm in a strange development situation and am a noob at the bits I'm tasked with - just to make life fun and interesting.
My fellow developer has written programs in VB.Net and placed them on the server. He wants a web front end that users can click a link and have that run the program on the server.
Sounds simple, but I've spent days searching the internet and found only two solutions one of which looks sketchy on security and the other is so complex I'm not sure how to make it fit my local variables.
I'm writing ASP.Net on an MVC Framework using C#.
So, in terms for the simple minded to understand, is there a way to do this? Are there links which I used the wrong keywords and completely missed? Or even a suggestion on which tech docs to look at to try and track this down.

I would have your fellow developer convert his application to a library that you can reference in your c#.. Doing what you want to do does not sound like a good idea at all and I would avoid it at almost all cost.

I have had similar requirements.
How I handled it: write another program that runs in memory on the server and is looking at my database (or file system) on a schedule. The ID of the application to run is then added to the DB/Filesystem from the web page; during the next scheduled check (mine checks every 5 seconds) any scheduled applications are run.
It isn't a direct execution, but gets the job done and is very straightforward.
FYI: My requirement was to do some office automation task.

Windows Mobile is hell for new developers? (If I'm not wrong)

I am new here and new to windows mobile development. But I have seen and experienced, for new developers having no trainers or experienced people around windows mobile development is like a hell shaking one. In complex topics you are going to find help from nowhere except you are lucky.
So my question is how should I gain expertise in windows mobile without having any trainer. The thing that i only know is C# and have a rough experience of one and a half months in windows mobile development

Yea.... it's quite a step to be honest. It's evil as well because at first glance it looks to be so very simple but then it turns around and bites you.
I speak from experience as I made this journey starting in 2003. Oh, I had no trainer either so I just learnt via bitter experience.
Know your limitations
I remember the first ever CF application. I was such an idiot..... I wasn't much good at developing back then either. First mistake I made was overestimating CF 1.0. I couldn't possibly imagine that the CF didn't have a read-write datagrid so I specced it...... then found out that oh yes, there wasn't one. So I had to write one myself (and remember I was rubbish at this time too). I hacked one into the existing datagrid (although tbh I should have just started from scratch). I remember that the "delete" function where I had to remove a row and then select the "now currently selected row" was hellish because it would go up or down depending on how many items were in the collection and where the scrollbar was.
There are many times that my desktop development buddies will categorise me as mad when I tell them what i'm working on.
"You're doing manual Xml Parsing? Are you crazy?"
"Ewwww code gen?"
"You.... re-use your windows forms?"
Yes, working on CF will make you look crazy to outsiders.
Performance
This can be taken to extremes but every little does help. If your building a big flexible application then think very carefully about perf. Consider replacing Reflection with codegen. Consider using an XmlReader instead of an XmlDocument. Sure this advice might be crazy in most cases for desktop but for CF it is sensible.
Know your PInvokes
In desktop land you can live in pure managed. No chance of that happening on CF. Some of the simplest things (playing a sound, setting the time, changing the volume, networking, etc etc) still only exist in the unmanaged world in Mobile. OpenNETCF have done an awesome job in exposing some of these but you will always stumble into one or two where you will need to write your own.
There is true, there is false but there is also FILE-NOT-FOUND
PowerManagement, how I love thee. In a usual C# app code goes the way of the logic (like a fork with an IF), perhaps an exception will be thrown and perhaps there will be many threads treading the path of the code. This is already complex. Add into the mix the idea that the power might vanish at any point. That's right, the using statement you were relying on to call Dispose might never call dispose because the device was turned off and then it ran out of power.
Device specific fun
Another big difference in desktop/mobile world is hardware and manufacturers. On the PC you can generally assume that the hardware will be okay and firmware updates should do the job. In CF a firmware update may well kill your code. Some hardware might sorta, kinda work if you bash it round the head in a certain way. Basically your device integration can (worst case) be a big black hole of time. Remember to work this into your estimates.

Learning to write actual maintainable, saleable and usable applications for the Compact Framework is difficult. The CF is way, way scaled down, so there is a lot that a desktop developer will not have that they are used to. I'd been developing CF applications since before the CF existed and I still find many things difficult (just try getting a control with transparency drawn into a container on a form with a background image and doing it without looking at the code in Project Resistance).
In my opinion, there really are 2 things that are essential.
You must be able to read and understand C/C++. All of the SDK docs are in C and a large amount of samples for using anything useful on the device tend to be in native code. If you can't translate that, you're at a serious disadvantage and you have to hope someone else has already done the work. Even if they have, they you have to rely on them having done it right.
You need CF experience. Desktop experience is largely worthless in the CF environment once you get past syntax. Laziness like data binding, using Data Sets, not cleaning up objects and all of those things that desktop developers do every day will kill a CF app. You need to throw out what you think you know and start re-learning. You do that by simply writing code every day.
Don't expect miracles either. I've been writing code for Windows CE for over a decade now and the amount of things I don't know about the platform still far outweighs the things that I do know.

If I understand your question....
If you have c# experience, you will not really need a trainer.
Building on Windows Mobile is very straight forward and easy if you know .net.
If you have Visual Studio (I think any edition apart from express), it is simply a matter of starting a new project and selecting mobile device.
I honestly love it! I build small applications all the time for my phone... little calculators for when I go shopping, programs that fire off a trigger and get a response from a web service and more... basically to make my phone do what I want (and no one else would be interested in).
I go by the method of simply writing an application the way I want and then if a feature is not supported by the cut down .net compact framework, I try and search for an alternative method that is - however, I have found little that doesn't work.

Developing in the CF can be challenging. Knowing C# is important before moving forward with the Compact Framework - to which you have. I would suggest that you start with smaller applications. Once you get the feel of Visual Studio and working with the emulator, I would suggest that you play around with a setup project. Once you get an idea on the flow of CF development, deployment will probably be your next step.
One area that I find that I spend time on is Designer support. If you are writing controls for other developers - design time support is crucial. Checkout the article at http://www.mooseworkssoftware.com/VS2005%20Control.htm for more information (I know its for VS2005, but it really helped our development).
As you move forward, create small projects in different areas and learn the pitfalls to each. An example would be GUI and dealing with different screen resolutions that are supported by different devices. Next, maybe DB support. After you get comfortable with a couple of areas, bring them together in a project and build from there.
Give it time - sometimes it will be painful, but the possiblities are endless in writing applications for the CF and what the market is calling for.
Craig

To answer your question, Windows Mobile is like paradise for new developers. You use the same tools and languages you are used to from the desktop world and essential things like in device debugging and emulators are just there for you. You can build simple applications with no training, just by following one of the many beginners tutorials available.
After that, there are of course many complicated and difficult issues to overcome, but in my opinion the fact that you will be able to start quickly is very important.
Also, you need to also need to compare Windows Mobile with other mobile platforms. Compared to platforms like Symbian, Brew and J2ME Windows Mobile is much more advantageous for new developers. I don't have experience with iPhone and can't comment about it, but comparing to everything else, Windows Mobile is easier.

Windows development for hardcore Java guy

I'm a little ashamed for asking this, because, you know, I've been very anti-MS for a long time. I have been fortunate enough as to make a living outside Visual Studio. As I grown older there are "some" things I would like to try, and to be very honest, this Q&A site has inspired me and I realize that VS and Windows Development doesn't suck that much. Hey, after all C# was designed after Java, and now Java is copying back some features from the child language. And Windows vista is the first decent version since windows came to light.
Anyway, to any +3,000 user in the audience, you may delete all the above crap and keep the following:
Do you have, links, resources, tutorial aimed to learn Windows development coming from strong Java background?
I'm very interested in Windows manipulation (that is the actual window, the frame, get the name, get foremost app etc., resize it programatically, etc.) and in Windows Search API among other minor API's. My interest after all is to integrate them with my Java apps through JNI or JNA.
I've read many tutorials and links over the MSDN, and I actually understand the API it self. I've grabbed a copy of C# and C++ Express and actually got some basic samples running.
My problem is I don't get the big picture of the whole architecture (because, well, it is big). The classes have hundreds of methods, and it not that clear to me who calls them. (I had this same opinion when I first look at the Java's Javadoc API.) I don't know some basic common objects, for instance HWCD (or something like that) that it turned out to be the very window handler, but every single tutorial I read give that for granted (as if WHCD or what ever it is, was a very descriptive name).
I don't know exactly the difference between Win32, COM, COM+, DCOM, Windows SDK ADO, and some other technologies. I mean, I know them at some degree and by common sense, but while reading the tutorials or the API I get confused. I've tried to grab some "beginner" tutorials, but they are aimed for absolute 0 programmers using Visual Basic (yiak! , THAT was the main reason I kept away from MS for so many years in first place.)
I do understand .NET framework, managed code, unmanaged code, C# basics, CLR and related stuff, because well, they are SO similar to the Java platform that it is almost transparent.
So, after all my rants and honest opinions about MS development:
What's the best way to learn Windows Development for a non absolute beginner (in programming) but absolute new to Windows APIs itself? What would be a good path?

The Petzold is your new best friend, and MSDN is your new Javadocs. Make sure you have a good understanding of C before you dive into it though. The Forger has a great beginner tutorial too if you're interested. A great place to hang out while learning is #WinProg on efnet irc, plenty of win32 gurus ready to help.

I'm going to suggest an alternate path (with less resistance). Have you looked at WPF yet? It's the new GUI toolkit that lets you create sexy interfaces (like those found in Vista).
That may be enough to keep you interested while easing into more advanced development. From there you can jump into the jungle of the Win APIs (if you choose).
Just a thought, as that path would be more interesting for me. Your mileage may vary, of course.

I strongly recommend getting yourself a copy of "Win32 Programming". It explains the basic DNA of WINDOWS - and this is valid if you are programming with the old C++ win32, the new C# WinForms and also the future Windows Presentation Foundation.
In a nutshell, a Windows program consists of a WinMain. When first started the app registers its window class with the system, initializes and then starts a message loop which continues till WM_QUIT is encountered. The system (OS) keeps pumping messages like keyboard or mouse click etc to the message Q of the application. In Windows, at any point of time there is only one active Window - so the OS knows whom to send the message to.
Well things like these are described in detail in the above book.
COM (COM+, DCOM) are not really related to Windows. When Word, Excel became popular and it was required to be able to access Excel from Word (viceversa) they came up with the AcitveX technology which is kind of the root for COM etc. You can get started with "Essential COM" by Don Box.
One warning: in the Microsoft world, there are two ways to program - to go the boiler plate way (write everything yourself) or use frameworks (MFC, ATL-COM....). It is recommended to do a bit of boiler plate so that you know the basics.

Having made the same conversion a year ago I can say that there's a lot of literature specifically for learning c# from a Java background. This was my first into which I found really useful for learning the important differences / features of C#:
C# from a Java developer's perspective
And there are also books which may be worth a look at (google 'c# for java programmers'). As JohnT said MSDN library is the equivalent of JavaDocs API, but I found it really frustrating to use. The best way to learn is to grab a copy of Visual Studio express and start playing around. Use intellisense to explore classes and methods. Find a small program you wrote in Java and try to reproduce it in C#. Start with simple problems, use google to solve them. You'll find it hard for the first week, but trust me, it will come to you surprisingly quickly!