I'd like to use Visual Studio Async CTP (Version 3) for developing and testing in VS2010 SP1 on Windows XP SP3 mainly because my clients (as well as I) on Windows XP SP3. Ghere is a related discussion on MSDN forum: If I target .net 4.0 but run on a machine that has .net 4.5 will .net 4.0 WPF bugs still be there?
Though, the NOTE ON "AS IS" LICENSE tells:
While the Async CTP license does not prevent you using it at your own
risk in production environments, we advise you not to. The goal of
this CTP is solely to gather feedback on our intended async design. We
did not design or build it to be used in production environments, and
did not test it as thoroughly as is needed for use in production
environments, and we believe it has too many flaws to be fit for use
in production environments. We gratefully appreciate feedback on the
Async CTP, but we do not plan to make any fixes to the Async CTP
itself: the fixes we make will only appear in the eventual supported
released product
How serious are those flaws and bugs, being abandoned in Visual Studio Async CTP (Version 3) and what are the possible other consideration that I should take into account which can force me to change my decision?
The main reasons of asking are that:
I did not follow much anything about C#/.NET 4.5 VS2012 topics (due to sticking to Windows XP SP3, .NET 4.0 and VS2010) and I need to reduce the time of bumping into critical issues;
I have never before been in a situation when I should probably follow the lists of bug fixes (instead of specific isolated issue on a by-need basis)
Do I really need now, for this case?
The main question:
What are the araes/possibilities that the unsupported flaws will not have easy workarounds in .NET/C# 4.0 in VS2010, Windows XP SP3 and those that can outweigh the benefits of using async/await
The asnwer to #DanPuzey's comment:
The application is based on TPL, WPF dealing with asynchronously coming from the internet (stock exchange) data flows. I have never before needed to care that I would be left with unsupported docs (samples), flaws and bugs. I probably will not be able to ask about them since they will not be reproducible by MSFT support as well as by others. I'd like to estimate the risks vs. benefits of using unsupported extensions
Are the main differences, flaws, bugs and risks infinite and cannot be enumerated? At all?
Let me cite from download page:
"Includes a new EULA for production use. Note - This license does not
constitute encouragement for you to use the CTP for your production
code. The CTP remains an unsupported and use-at-your-own-risk
Technology Preview. However, we’ve received many requests from
developers to use the CTP for production code, and so have changed the
license to allow that"
The answer to #CodesInChaos' comment:
This is not the option as it was mentioned in the beginning of my question with reference to preventer link description here discussion. One cannot develop and test .NET 4.0 app from VS2012 or machine having .NET 4.5. It is impossible to install VS2012 or .NET4.5 on Windows XP. My experience (tried to install apps from other vendors) is that mentioned by you approach does not produce apps running on Windows XP
I second #CodesInChaos' recommendation that you develop using VS2012. I use VS2012 on Windows 7 to develop .NET 4 apps running on Windows XP, and it works fine. The only caveat is that you can't debug on .NET 4 (you actually run on the .NET 4.5 runtime), but for 99% of the cases that doesn't matter.
I did use Async CTP in production; I considered it surprisingly stable for a CTP. That said, there are some known bugs. Most notable was the ordering of operations around await expressions. So follow the guideline of only having one await per statement, and make the await expression your top-level expression, e.g.:
var result = await ...;
I believe Jon Skeet also uncovered some more obscure bugs during his eduasync series.
There is no list of Async CTP bugs that have been fixed, or that still exist (in Microsoft.Bcl.Async). There may be some list inside Microsoft, but no one else knows it.
The application is based on TPL, WPF dealing with asynchronously coming from the internet (stock exchange) data flows.
In that case, consider Rx. Rx is fully supported on .NET 4, though I believe it does require VS2012 for development.
Related
I will refer applications in Windows Store for either Windows 8/8.1 or Windows 10 as UWP applications as Wikipedia does, if I do not mistake it. Windows RT(not WinRT though) is not discussed to avoid confusion.
I wonder what API's no matter public or undocumented that Windows 8/8.1/10 have implemented that Windows Store and UWP applications rely on, so that they cannot be port to Windows 7, which is NT 6 as Windows 8/8.1/10 do.
If nothing much are there, but only due to M$'s market strategy to promote new technology'd Metro, there might have been some 3rd-party runtime/framework for Windows 7 on which Windows Store will work and UWP applications can run, which will surely spend no more effort and cause no more legal or compatibility trouble than Mono or Wine.
Edit: As How does Windows 8 Runtime (WinRT / Windows Store apps / Windows 10 Universal App) compare to Silverlight and WPF? says, it's a layer quite similar to .NET that lies between COM and application, if I didn't misread.
It's not a marketing strategy by the evil M$, and writing things like that makes you look rather juvenile. There's a giant layer of code (arguably an entire operating system within an operating system) that was written to enable Metro/Modern/UWP apps to run in Windows 8, tweaked in 8.1, and further refined in 10. That layer simply isn't there in Windows 7, wasn't backported, isn't going to be backported, and can't reasonably be backported by a third party who lacks access to the undocumented details of the implementation.
There is no conspiracy afoot here. It is a simple matter of new operating systems supporting things that old operating systems don't. The new features that Windows 8/8.1/10 have implemented that Windows Store and UWP applications rely on is the entire notion of a Windows Store and a UWP application.
The version number ("NT 6", as you point out) doesn't matter. All that tells you is they didn't massively rewrite the kernel. You don't have to rewrite the kernel in order to write a new layer on top of it.
If you want to run Metro/Modern/UWP/Store applications, you need to update to a later version of Windows. Alternatively, you can just write a regular Win32 application, which will run on all versions of Windows, including the latest builds of Windows 10.
So we have developed an application that uses the .net 4.0 full(extended) libraries. Our workstations only have .Net 4.0 client on them. Our applications and infrastructure teams are wary about having us deploy .Net 4.0 full to all the workstations and wants to take some time to discuss and test.
Is there some way to deploy the extra .Net Extended dlls with our application so we can go around this?
No, you cannot supplement with just the dlls. All you can do is update to the full profile or find the features in your app that require the full profile and re-write them to avoid that requirement.
There's actually not that much difference between the two profiles. See the answers to this question for a more complete explanation:
Client Profile vs Full
That means that you may have an easier time than you think either re-writing the app to avoid the features, or convincing your staff to update the profile deployed to the workstations. It's likely just some advanced WCF features or a type provided with ASP.Net (like HttpUtility) that you're missing.
All,
I'm attempting to estimate the effort to port an app developed on Windows (.NET) to Linux (Mono). I came across the MoMA tool, which attempts to look through my .exe and find potential areas of incompatibility. Most of my issues appear to be centered around get/set of network settings, getting network info, etc. (Object ManagementBaseObject.get_Item and set_Item. etc).
In almost all of the cases, the Mono functionality is listed as "ToDo". For estimation purposes, is it safe to assume most/all of these have some kind of workaround? I would imagine this type of basic networking support must be included in the latest version of Mono. Or should I assume none of this is currently available and I would be stuck waiting for it to be implemented (or be forced to implement it myself)?
Thanks,
Dan
First,see Mono Compatible Networking/Socket Library. Also,take a look on Cross-Platform Network Applications with Mono. You can start with C# Network Library.
We are considering to change our present .net2 on IIS6 server to .net4 (or 4.5). Can someone help us with some basics about this?
After we install .net4 to our production IIS. Is every .net site defaulting to .net4?
we have had some dificulties with 64-bit version so we have forced IIS6 to run in 32-bit mode. Does update do something to this? After installing .net4, how can we force specific application pool to operate on .net2 mode and on 32.bit mode?
What problems there might come out on transforming .net2 sites directly to .net 4 sites? Or is there any?
It's been a while since I've last used .NET, but here's my general suggestion.
First, Migrate to .NET 4! .NET 4 offers better security and new features. Consider that as your first option.
Second, in my experience, if you have multiple versions of framework installed on the server, you should be able to choose which version to operate that site.
Lastly, I'm not sure about 32/64 bit thing, but my suggestion is to simply fix it! Applications, especially heavy-load applications can operate better in 64-bit mode.
Make you application as future-proof as possible!
As for what problems you might run into, I really depends on what kind of APIs you're using, chances are, they will be a few deprecated methods, properties. Also, look at some new features, there might be new APIs worth trying, try that at a development server, it might increase overall user experience and even application performance.
Good luck!
Is every .net site defaulting to .net4?
When you add some website to IIS, it is assigned "DefaultAppPool" by default. So, it depends on what version of .NET framework set for your "DefaultAppPool". You can change application pool to target specific .NET framework.
After installing .net4, how can we force specific application pool to operate on .net2 mode
You can define more than one Application Pools in IIS targeting different .NET frameworks and then assign different Application Pools to different websites.
What problems there might come out on transforming .net2 sites directly to .net 4 sites? Or is there any?
I think it usually depends on your website; the libraries referenced, the patterns used, etc. No one can give you clear answer of it.
What is a better platform/language for developing Windows/desktop based application that can run offline (sometimes)? .NET (C#, ASP) or Java or any other development tool? This application requires to store data into a database(involves some GIS) and later Synch both ways with the main server (SQL/Oracle) during off hours or when initiated by a user or event or when online? ALso the tool/IDE recommended should allow us in the future to migrate this desktop application as a Web based application to the corporate server with less pain or re-work when internet/nw access is available to all of our remote sites/users. Any input/advice is appreciated.
If you are strictly doing Windows desktop application development, C# or VB.NET would be an excellent choice. There is a ton of documentation out there for .NET developers. Although the framework is a free download from Microsoft, any serious work is cumbersome and tedious without the IDE.
If you needed the potential to support your application on multiple operating systems besides Microsoft Windows, then I think it might be worth looking into Java.
For web solutions, in .NET you have ASP.NET, Java you have JSP and Tomcat.
You could try Adobe AIR. It seems like it would serve most of your desktop needs and it should be the easiest to migrate into a web app (Flex).
C#/WPF for desktop with Silverlight, XBAP or even ASP as the online options.
Since you mentioned the desire to web-enable this application at some point I'd look into Silverlight. Out-of-browser capabilities were introduced in Silverlight 3. That means that the app can run directly on the desktop, and the internet connection is optional. However, when the internet connection is available it has built-in support for auto-updating itself.
And now in Silverlight 4 it's possible to run an out-of-browser Silverlight app with elevated trust. Silverlight 4 also finally introduced things like right-click support, clipboard access, full keyboard support in fullscreen mode, etc. So if you're just now starting development, I'd most definitely use version 4.
You'll have to communicate with something like a WCF service for a lot of the database operations. But going with Silverlight should allow you to build something that'll work on the desktop and the web alike without having to manage two systems.
Going web-based after you already developed a desktop application is a really bad idea. There is no reason the desktop application cannot use a internet connection, and be updated from a server.
You could try Delphi. It's a rapid application development tool. Very different, but very quick to use. Well suited to Oracle integration. Data sync is probably going to need to be custom, unless you're using something like Sybase SQL Anywhere.