I moved to Kinect for Windows 2.0, and I want to run a sample from the 1.x series, and obviously Visual Studio shoves me 80++ errors.
Searching on the web was useless, I found no documentations for porting old code to 2.0, or at least, I wasn't able to find any good source.
Has anyone succeeded in running old examples on the new KFW2?
Thanks!
API has certainly changed, you will have to create wrapper (adapter pattern) around sdk 2.0 or correct your code to use newer API. In every case you will have to alter our original code to some extend. Altho there are some similarities there is no simple "converter-like" solution.
Related
I am intending to write code to determine if the OS is Windows XP, so I can set the LOCALAPPDATA environment variable to work-around a whole load of code which uses ExpandEnvironmentVariables() heavily.
To make it even more fun, some code is written in VB6, and some code is written in C# 4.0 . Looking at the documentation for GetVersionEx(), there are strong suggestions that this API call will be deprecated from Windows 8.1 onwards. But no problem, there is a different set of API calls (VerifyVersionInfo / VerSetConditionMask) I can use. With VB6, there is no choice - I have to use the API call.
However, with my C# code, there appears to be no obvious equivalent. There is Environment.OSVersion, but this seems to be a hacked together set of data from disparate sources, and there isn't anything with the subtlety of the VerifyVersionInfo() API.
Is there a wrapper for this API call. If not, should I bother implementating it myself?
[Added]
Or otherwise, maybe someone might have some internal information about how the Environment.OSVersion is implemented?
First of all it is important to understand what Deprecated means. It means that the function either is critically broken (such as some early threading), or that it's been superseded (replaced) with new functionality. In this case it is the latter.
From the documentation on GetVersionEx function there is a link suggesting to use Version Helper APIs instead.
One part of this page is specifically important:
Note These APIs are defined by versionhelper.h, which is included in
the Windows 8.1 Preview software development kit (SDK). This file can
be used with other Microsoft Visual Studio releases to implement the
same functionality for Windows versions prior to Windows 8.1 Preview.
It's perfectly fine to use GetVersionEx. It won't be removed from Windows for a very long time, if ever. Microsoft has a long track record of maintaining compatibility with old programs. For example, you can still call the Win16 APIs that were deprecated 20 years ago.
I added an additional part to my original question about whether anybody knew about the internals of the Environment.OSVersion object. After searching around this site for a few minutes, I found this question:
How to detect Windows 64-bit platform with .NET?
Now, the "official" answer itself wasn't very interesting to me, but the second answer from Phil Devaney mentioned an application called "Reflector" that appeared to do some sort of magic. So I downloaded it, and blow me down, I was able to decompile the P-Code for the Environment.OSVersion object's constructor:
Win32Native.OSVERSIONINFO osVer = new Win32Native.OSVERSIONINFO();
if (!GetVersion(osVer))
{
throw new InvalidOperationException(GetResourceString("InvalidOperation_GetVersion"));
}
So that's it: Environment.OSVersion internally uses GetVersion, a function which might not behave itself in future days. Looks as if VerifyVersionInfo and P/Invoke is the way to go on this one.
I will now have to download .NET 4.5 on a different machine and see if that implementation is any different.
Mark)
Maybe it will interesting for you GetVersionExEx
But please note that VerifyVersionInfo may also be deprecated in later releases of Windows OS (as stated by ms tech guy in msdn social forum).
This code depends on VerifyVersionInfo and provides same usage experience. Also bisection algo was used in code.
Version Helper API for requests to API, this code for exact values.
Thanks)
I m working on a facebook ap with Facebook C# SDK and MVC 3.
One of the problem I m having is: multiple versions of Facebook SDK API with several inconsistent versions. Almost every version there is a change in the API and something that works in one version doesnt work in another. There are also major changes between API versions.
I m using the latest version. (6.0.12). I cant find any documentation on how to use the API.
API website has lot of TODO pages. (http://csharpsdk.org/) and documentation is not concise.
Should I use another SDK ? What do you recommend? or are there any samples I can use for this version?
Thanks.
I'm much in the same boat as you.
I've followed the blog posts from the members of the Facebook c# SDK team, and their reasoning behind doing the latest major re-work of the API. I'm optimistic and think it's a healthy decision, leveraging the majority of the work from the server to the client instead.
In the end, I think it will benefit our applications with a much more scalable and performant solution than before with the earlier SDK. A good thing if your application gets viral.
The earlier versions had good and plenty samples and documentation, I only hope that in time the team will be able to provide that with the newer version as well.
For me, I currently have a v5.0x solution in prod, and I'm very eager to jump on the newer SDK, but I'm holding on for good samples as well, hoping for some magic during the upcoming months.
It's really a question on how long you can wait, I think it's the best SDK out there at this point.
If anyone is having problems with FB breaking old versions like I did, here is a small and brief tutorial I created
http://theocdcoder.com/tutorial-integrating-facebook-authentication-asp-net-mvc-3/
I'm looking for a library that can be used in native .NET code, just like any .NET assembly. The purpose of the library must be to automate Windows (push a button, select a window, send keys, record & playback, that sort of thing).
So: the library is supposed to be used natively in .NET, but the automation itself must be able to target any native or .NET Windows application that can receive user input.
Suggestions so far:
benPearce suggested AutoIt. It has a DLL, which is native Win32 but not native .NET and cannot be used without use of .NET Interop.
Chris Dunaway suggested Global Mouse Keyboard Lib. This came closest, but is not an automation lib. It just helps setting up keyboard and mouse hooks.
pm100 suggested Microsoft's WPF UI Automation. This one is pretty good, albeit that it's not available if you develop in .NET 2.0 and it requires the WPF to be installed on the system. It can, however, automate everything from Win32 apps to HTML in a browser.
JasonTrue suggested WebAI from ArtOfTest. This is a testing framework mainly geared towards browsers and web applications. It is unfortunately not well suitable for use for Windows automation.
If nothing else appears available, I'll probably choose Microsoft's UI Automation and upgrade any projects that require it that are still in .NET 2.0 to .NET 3.5, if possible. But I hope for a more widely applicable automation framework (.NET prior to 2.0 does not need to be supported).
Have you looked at the White framework?
I have used AutoIt in the past with success.
microsoft's own built in one is fine
http://msdn.microsoft.com/en-us/library/ms747327.aspx
not restricted to wpf as some seem to think.
If you haven't seen it yet, and a commercial library is acceptable, you might check out Ranorex:
http://www.ranorex.com/
I used Ranorex 1.5 quite a bit to write small C# UI automation utilities. It was pretty effective! Development seemed faster compared to using the MS UI Automation API directly, since Ranorex has a lot of useful convenience methods already available.
I haven't used Ranorex 2 very much yet, though.
In Ranorex 1.5, there was also support for traditional Win32 development in C++, but I didn't use it. As far as I know, that's still available in Ranorex 2.
I can't speak to the quality of the record/playback support in Ranorex since I never used that feature.
One final plus: Their support team was really responsive and helpful anytime I emailed them.
This library is pretty interesting and is fairly simple. Perhaps it will help you.
Check out Tools for automated GUI testing on windows
I would still suggest FlaUI for autoamating .Net Desktop,Mobile apps. Its based on Microsoft UIA libraries and have support for external controls like the DevExpress Grid too
Moreover, it is built on top of TestStack.White so indeed a very good library and has a github page also
I have used WebAii from ArtOfTest with a fair degree of success in automating integration testing for a Silverlight app. It also supports WinForms and Web applications.
Microsoft UI Automation, the successor to Active Accessibility, can do almost all of the Windows UI automation you would need.
How about CSharpScript, here's an article about it on Codeproject, and here's the link to the main website. Furthermore, it is familiar C#, scripted which can be used to automate anything.
Hope this helps,
Best regards,
Tom.
I love programming with .NET, especially C# 3.0, .NET 3.5 and WPF. But what I especially like is that with Mono .NET is really platform-independent.
Now I heard about the Olive Project in Mono. I couldn't find some kind of Beta.
Does it already work? Have any of you made any experiences with it?
Edit: I know about Moonlight. But I want a standalone WPF application. And because of Moonlight I hope WPF on Linux will become true.
You'll have better luck working with Moonlight, which targets the Silverlight API, which is a subset of full WPF.
edit: Sure, Silverlight isn't "intended" for the desktop, but there's no reason why you can't embed a silverlight engine in your application. It's been done before, such as for the Mac NY Times Reader
more edit: see Miguel's post on Standalone Silverlight Applications
Update: Since people keep upvoting this, I want to point out it is long since out of date. Mono got acquired by MS years ago, and their posture regarding open-source has changed, so consider this post obsolete. (As obsolete as the WPF framework itself, heh).
Mono is in a bit of an uncomfortable position when it comes to Microsoft APIs such as Winforms and WPF. A subset of the .Net technology is an ECMA standard, but free implementations of these APIs are probably on shakier legal ground. I believe this was a large factor in the covenant between Novell and Microsoft, which is good for Novell customers. But people who use Mono that aren't customers of Novell aren't protected. For this reason a lot of people in the F/OSS community look askance at Mono despite its technical merits.
For this reason, Gtk# will always be preferred, since it is truly Free. Many people consider it to be superior to Winforms anyway. As far as WPF is concerned, it will almost certainly be a low priority for Novell. They may implement it eventually, but I would expect Moonlight to be the closest you could get for the forseeable future.
Since posting this, Microsoft has extended their covenant to anybody who implements the ECMA 334 & 335 standards.
From the mono website
At this point, the Mono project does
not have plans to implement Windows
Presentation Foundation APIs as
part of the project.
Moonlight is an implementation of silverlight, which is a browser based flash like technology based on a subset of WPF.
In my opinion the choice to not implement WPF is monos biggest mistake. As WPF is fast becoming the default choice for new .net user interfaces. See this blog for more.
There is a library called Silverform SDK that aims to provide cross-platform WPF and Silverlight implementation.
The library is implemented in managed code and currently works with OpenTK and Unity3D as render backends. Major functionality, such as binding, layout, main controls and primitives, has already been implemented (check Unity web player demos here). Initially it has been focused on Unity3d render, while support for standalone Mono applications will be added as a separate build in the future.
Disclaimer: I am one of the developers of the library.
If you check Known bugs of this link(also includes steps needed to install .NET onto Ubuntu)or this you may find that some(may be buggy) version of WPF works on Wine as for now. I did not find any definite test done as for now, but worth to try to run WPF "Hello world".
UPDATE2:
I have run latest IlSpy on latest Wine for Ubuntu 16.04. With 32 bit version of dotnet45 and corefonts installed via winetricks with windows 7 compatibility.
For this time no crashes and all things work fine. Fonts look really good.
IlSpy is shown via WPF and for person who loves programming with .NET is essential tool - the decompiler.
I downloaded latest portable SharpDevelop(build using WPF) with no extra. It started. Failed to create WPF project. Created WinForms. After opening some cs files and evidencing some glitches, tried to type - and it crashed.
UPDATE
I followed steps and got latest ILSpy.exe running on Ubuntu 14.4.
Next items to note:
wine stated that dotnet40 is not supported by 64 configuration, changed to 32 bit
fonts are ugly, but readable
basic functional works fine - I can see decompiled code - which is good enough for some development, but View -> Search and View -> Options -> Display crash.
Conclusion:
WPF on Linux is possible. But need some way to tackle issues.
From the Olive home page:
Olive is unsupported, should be
considered as experimental software,
and since it implements a shifting API
there are no guarantees of any kind
about the stability of the API.
I doubt anyone would have used it in a real project.
Yes, it is possible using NoesisGUI a real-time multi-platform XAML implementation. There are a few games already released using this technology in Linux, like VoidExpanse
Disclosure: I am one of the developers of this product.
I heard a podcast interviewing miguel de icaza (the mono lead) maybe a few weeks ago, so that would have been maybe mid-december 2008, and he said that they had no WPF support at all yet.
Theoretically, a stripped version of WPF COULD be compiled against WinPR or LibWine to run on Linux.
Currently there is no such setup, so someone would need to make one. Hopefully this might change soon.
As of running against or in a full Wine environment, I think that is seriously overkill and will result in too much bloat to be worth making a very small number of additional programs work.
My company has an existing established WinForm application which in running on WinXP. The application does alot of sound processing using DirectSound.
My company would like to evaluate Mono, as an alternative on a per workstation cost to Vista/Win Server 2008.
I've heard that different estimates, ranging from 'it will work easily on Mono' to 'it could take months of recoding in certain cases to get a WinForm app to run with Mono on Linux'.
Does anyone have a good real world experience with this?
A good link reference?
I would like to get a better idea before I commit to testing.
Thanks!
The WinForms part will be easy, you may have to do very little as Mono now claims to support Winforms 100%, however all the DirectSound calls will have to be rewritten to use an API available on Linux, ALSA being the obvious choice.
I have written small apps in VS 2005 and ported them with ease to Mono. If you do a lot of P/Invokes, then you'll have to take that into account, as those may have to be completely rewritten or rethought.
Also, check out MOMA: "The Mono Migration Analyzer (MoMA) tool helps you identify issues you may have when porting your .Net application to Mono. It helps pinpoint platform specific calls (P/Invoke) and areas that are not yet supported by the Mono project."
Mono can help you move the managed code, but it will not help you move the audio layer.
Sadly, the .NET framework does not provide a comprehensive API for audio processing. It merely provides a way of playing back a small sound sample, and it is not even very good at this (See Jeroen's post about audio gaps when running the C64 emulator under IKVM).
You will have to research which Linux API maps best to what your audio application is doing.
Lennart Poettering blog entry on audio is an excellent starting point:
http://0pointer.de/blog/projects/guide-to-sound-apis.html
Once you decide on an API, just like in Windows, you will have to P/Invoke the API that is right for you.