We Keep Coding

What are the basics for switching from DirectX to SlimDX?

I have an old application for playing video that uses DirectX and I would like to update it and prevent the "error" of Loader lock among other things.
Can I ask what are the basic steps for converting the application? What do I have to pay special attention to?
Currently I have references in the project that point to local DLL files that I have added to a local folder. This is not a good approach and another reason for this question.
Microsoft.DirectX
Microsoft.DirectX.DirectInput

You'll need to change the namespaces to the SlimDx namespaces. At that point, you'll have to migrate some code, as some of the names are different in SlimDx vs. Managed DirectX.
That being said, the basic API calls for DirectX 9 are very similar, so the migration is not too bad once you get going.

I'm a little late to this thread, but I have used SlimDX for a year and I'm nearly but not quite finished translating my embryonic game to SharpDX (because I want to use XAML and a couple other reasons). I highly recommend both, and putting aside SharpDX's advantages (DX11.1, WinRT, XAML, some speed improvements), I would say that SlimDX is as close to managed DX as your going to get, it's equal to SharpDX, without considering those advantages that I mentioned.
I hope the point I'm making is that SlimDX is a closely mapped framework, equal to SharpDX. In that regard, SharpDX can't be recommended alone, without mention of SlimDX. And also I want to make the point that SharpDX will not minimize the migration steps over SlimDX, if that's what you're thinking. They are very similar, more similar than you think if you are of the opinion that you might fail in one and succeed in the other. If you can work it out in one, then you can work it out in the other, they are that much alike. So much alike that I wished they would rejoin as a team and work together on a unified package of frameworks. There is just too much overlap for them to be distinct projects IMO.

Which IP Framework (If Any) to use in C# .Net 4

It seems that System.net.Sockets had some performance problems in multithreaded applications in previous versions of .Net. and that SocketAsyncEventArgs was (At least partially) created to address these. However it looks like using SocketAsyncEventArgs and getting it right is a nontrivial process as shown in this article.
Ive looked at some frameworksthat might be of use http://nitoasync.codeplex.com/ & http://supersocket.codeplex.com/
If I was looking for Maximum performance in an TCP application using managed code should I write around SocketAsyncEventArgs? and run the risk of discovering performance problems in production which are impossible to replicate in testing or should I use one of aforementioned frameworks?.
I am not working with C# that long. Most of my experience has been in C++ but I have zero experience in this area. Im using .Net 4

If you're looking for something free, I've had good experiences with SuperSocket.
However, if you need a bit more functionality...http://www.chilkatsoft.com/socket-dotnet.asp is really worth the extra dime.
Regular updates, and very easy to work with. Lots of examples, and thorough/good documentation for the most part (some of the functions (very few), contain a "To be documented")
The examples are really what sets them apart, imo.

Effort estimation: using C / Win32 or learning C# / .NET

I intend to write a small application to scratch a personal itch and probably make the life of some colleagues easier. Here is what I have:
10+ years of experience in C
Plenty of experience in programming against the Win16/32 API in C from the Win3.1 to 2000 days.
C library written by myself already doing about 75% of what the application shall do.
What the application shall do:
open a binary, feed it into the mentioned library.
take the resulting text output and feed it into a new Excel Workbook.
apply some formating.
integrate nicely with the Windows environment (availability in "Open With...", remember some stuff using the registry etc.)
(maybe later) before giving the CSV data to Excel, parse it by looking up the meaning of some values in an XML file.
Except for the XML parsing part I have done all of that stuff before including COM / Office Automation in C/Win32. There is a lot of boilerplate code involved, but it is doable and the result will be a pretty small application without the need for an installer.
So why even think about C# / .Net?
no experience with parsing XML
the promise of less boilerplate code for the Windows and Excel stuff (yes, I have done C++ with OWL, MFC, ATL etc. but I am not going there anymore - not for free/fun)
Since I have also experience with C++, VB(not .Net) and a little Java / Objective-C I suppose learning C# will all be about the .Net libraries and not actually about the language.
My considerations so far:
Learning .NET might be fun and might result in less code / first steps in a more modern environment.
Sticking with what I know will lead to a predictable outcome in terms of effort and function (except for the optional XML stuff)
VB looked great at the beginning until the projects where about 80% done, then the pain started and the DLL coding in C. I am concerned history could repeat itself if I choose .Net.
My primary objective is the functionality. Effort is a concern. The XML parsing is optional.
Please advice.
Update: one thing I forgot to mention explicitly is that I am also worried about easy deployment of the tool to my co-workers. With Win32 I am pretty sure I can come up with an EXE file < 1Mb that can be easily emailed and does not require installation. With .Net not so much. Can I create the necessary MSI or whatever in Visual Studio Express (free) or do I need 3rd party tools?

as others have your question mostly covered, I'd just like to quickly comment on your considerations:
Learning .NET might be fun and might result in less code / first steps in a more modern environment.
Totally agreed. It is definitely fun and usually it does result in less code. The investment you make now will certainly benefit you in future projects. It is way faster to program in .Net than in C. Not only it is easier, but it is also safer. You are isolated from many programming errors common in C mostly related to memory mismanagement. You also get a very complete managed API to do stuff you would usually need to build your own framework.
Sticking with what I know will lead to a predictable outcome in terms of effort and function (except for the optional XML stuff)
Hence your indecision. :-)
VB looked great at the beginning until the projects where about 80% done, then the pain started and the DLL coding in C. I am concerned history could repeat itself if I choose .Net. My primary objective is the functionality. Effort is a concern. The XML parsing is optional.
.Net is an entirely different beast from VB. Most of the things you wouldn't be able to do in VB, or at least do them easily, are supported by .Net. For instance, Windows Services are a snap to build in .Net. Socket programming is also supported, but there are very few reasons to do it yourself, as you've got loads of communication APIs with .Net. You've got web-services, .Net Remoting, MSMQ management, and more recently WCF. Proper multithreading is supported by .Net, unlike the idiotic apartment model in VB. In case you really need to go low level, you can also actually use pointers in C#, inside of unsafe code blocks, even though I would never advise to do so.
If you really need to do things in C, then integrating is also relatively easy. You can create COM objects and use interop to work with them from .Net. You can also interact directly with plain ol' dlls using DllImport. Using www.pinvoke.net makes it easier.
When I developed in VB, sometimes I also had to go back to C++ to do stuff that I wasn't able of doing in VB. Since I began programming in .Net, the only extremely rare scenarios I would need to go back to C++ were when I needed to use legacy COM components that used types I was having a hard time to marshal via interop. I wouldn't worry about history repeating itself.

If you're using COM, you may be interested in using C# 4.0 instead of earlier versions - the downside being that it's only in beta. But basically it makes COM stuff somewhat less ugly for various reasons.
I'd expect there to be plenty of good C libraries for XML parsing by now. I would expect the main benefit to actually be the knowledge gained. I doubt that you'll actually produce the code faster for this project, but the next one may well be a lot quicker.
How much do you care about learning new stuff?

It sounds like an ideal project for learning C# & .NET.
You know most of what you need to do so you can use that to gain a base level of understanding of C# & .NET which you can then apply to the stuff you need to learn.
As Rune says though, a key driver could be the timescales. If this is something you need in a hurry then coding it in C & using win32 directly might be the answer.
Sorry I couldn't be more definite.

I think you should use C#. With your experience the learning curve won't be too steep. The code will ultimately be cleaner (and less of it) than you probably could with C/Win32.
There is probably going to be no problem using your existing C-library with the [DllImport] attribute.

It depends. :-) It depends on whether you want to do this quickly or if you want to learn something new. It depends on whether you will be the only maintainer of the code or if others will maintain it in the future. It depends on how complex your xml handling will be and on how complex the COM automation is.
You will probably get a working application quicker if you do it in C than in C#. Both since you have much of the stuff needed already in place and since you know C well.
But this project sounds like a good match for C# and .Net. .Net has great support for XML and COM interop is easy but clumsy in C# (much better in the next version!). So if you are interested in learning C# and .Net this would be a good project to do so.
I would definitely do this in .Net and probably C# (but I am biased). Using .Net would probably result in code that is easier to read and maintain and most probably easier to write. So if you are interested in learning C# I would suggest you go for it!
Edit:
You worry about the size of the executable if you write it in .Net. I doubt that will be a problem, for most if not all of the libraries you will use for a project like this will already be installed on your computer. 1 Mb is rather large for a .Net executable, event for a big project.

a short notice on the installation. .NET is as default xcopy-able so you wouldn't need an installer for the exe to be usable. Mail it around (or with the next release of the .NET framework optionaly leave it on a network share)

You could look at building a hybrid system that uses C++/CLI and C#. C++/CLI provides a nice bridge between the two and lets you easily split different parts of the system between the managed and unmanaged worlds.
Not sure if the setup projects are included in the free versions of visual studio. But you could use clickonce (included with the framework) or WIX (open source XML based msi creation tool).

learning C# will all be about the .Net libraries and not actually about the language
No there are many things you need to learn about the language (delegates , events , generics ...) and also it is object oriented and it manages the memory by itself and yes no pointers :)
anyway C# and .NET are great all you need is some effort to get up to speed

C# linear algebra library

Is there stable linear algebra (more specifically, vectors, matrices, multidimensional arrays and basic operations on them) library for C#?
Search yielded a few open source libraries which are either not updated for couple of years or are in an early beta stage - and Centerspace NMath. Which alternatives are worth checking?

Math.NET. We're using it in production.

See: http://en.wikipedia.org/wiki/List_of_numerical_libraries
http://www.alglib.net/ - Open source. Multi-language library.
http://www.mathdotnet.com/ - Open source. As mentioned by others. dnAnalytics is replaced by http://numerics.mathdotnet.com/ in this.
http://www.lutzroeder.com/dotnet/ - Lutz Roeder has a open source port Mapack.Net of LAPACK.
http://www.extremeoptimization.com/ - Commercial.

I am using ILNumerics.NET
www.ilnumerics.net
Very good support and stable. I don't have any comparison though.

We have evaluated nMath and were quite pleased with its programmability and speed. Their support staff even worked over a weekend to figure out a bug we found. We liked that they used Intel's Kernel Math library instead of rolling their own numerics. [Edited to add: have been using in production for years]

Few weeks ago I found a new c# library FinMath contains implementations of many various methods and techniques including basic linear algebra, such as:
Vector and Matrix implementations (easy to use high-level interfaces covering most of all BLAS functionality)
Algorithms of matrix factorizations (LU, QR, SVD, Cholesky).
And many other useful things like statistics, factor and cluster analysis, linear and quadratic programming solver and etc.
Unfortunately, it's not free, but it's extremely fast, because it uses MKL for most complex computations and at the same time it distributed as single library supports both 32bit and 64bit modes and requires no special maintenance to use, like taking care about native libraries.

Have you looked into dnAnalytics?

Although it is not updated, not open source, and not for commercial usage, one might want to check out D* from Microsoft Research. It's a very cool symbolic math library, especially for doing derivatives, but really it's a little matlab in the hands of a .NET programmer.
http://research.microsoft.com/en-us/downloads/4714703d-782c-4e37-830d-0e3b7662f743

Should I prefer purchasing a commercial framework or creating my own version of the same functionality? (classic "Create vs Buy")

I have mixed views about commercial class libraries. Am I better off using a commercial class library or starting from scratch? If buying a library is the way forward which one for a C# developer?

Put a value on your time, say $30 an hour. Estimate how long it would take you to write the library, then add two times that for debugging and testing. Subtract the time it's going to take you to learn how to use the commercial library with the given documentation. Multiply by your hourly rate. Compare.
Writing a library can be fun and rewarding, but "not invented here" syndrome keeps a lot of companies from creating anything useful, as they're stuck reinventing the wheel for additional cost. Make sure it is extensible (if you don't get access to the source) and has what you need. Buy it.
As a personal project, it's probably worth writing it from scratch at least once to see what you can learn, but on company dime you need to be productive and efficient.
Or write it from scratch and release it open source ;)

I really think you are missing out the most important strategy:
Use open source and contribute changes back to the community.
I have seen lots of commercial software integrations go bad, usually because of real-life demands that are not met by the commercial product, many of which you do not discover until you are deeply committed (oh, so you wanted search to NOT have an upper limit of 1000 responses? No, we can't do that...)
If these things happen to you with open source, you at least always have the option of forking.

Always use a good quality library wherever possible - but only if you can have the source code. Experience tells me to not use anything that I can't have the source for.
Also - depending on what the library is, it is sometimes sensible to have a layer on top of it so you reduce dependencies, thus making any future replacement of a library easier.

That depends on your goals. If you want to experiment and learn about a certain framework feature it makes sense to try to implement it.
However, if you're trying to make money (or fame or whatever) on your software, you should ask yourself how to best spend your time. How much value do you add to the application by implementing yet another Linked List? Probably not a lot, so use whatever good implementations available. On the other hand, you could add value to your application by implementing a very specific graph control (although there are plenty on the market). So look at it from a return on investment point of view.