I faced a strange behavior using the following code:
FileDialog openFileDialog1;
// ...
openFileDialog1.CustomPlaces.Add(#"C:\whatever\");
This compiles with no errors using .NET framework 2.0.
The code runs well under Windows 7.
But under Windows XP I get the following error at runtime:
System.MissingMethodException: Method not found: 'System.Windows.Forms.FileDialogCustomPlacesCollection System.Windows.Forms.FilaDialog.get_CustomPlaces()'.
Trying to figure out the problem tells me:
Visual Studio 2005 help don't know about the CustomPlaces property of FileDialog
MSDN says that this property exists only since framework 3.5 - and "On Windows XP, this property does not have any effect."
Visual Studio 2005 intellisense offers me the exsistence of the property (so I thought using this property is fine)
That obviously doesn't fit toghether.
I still want to use the code, so I'm trying to figure out how a do check before calling it:
if (...) {
openFileDialog1.CustomPlaces.Add(#"C:\whatever\");
}
My question is:
Is CustomPlaces not supported by .NET 2.0 or is is not supported by Windows XP?
How do I handle this correctly?
1) Do I have to check for the Windows version:
if (Environment.OSVersion.Version.Major >= 6) ...
2) Or do I have to check for the framework version:
if (Environment.Version.Major >= 4) ...
3) Or both, or else !?
It seems you have answered your own question in your post. The MSDN documentation clearly states that the FileDialog.CustomPlaces property exists only from .Net Framework 3.5 onwards. If your application is running on .Net Framework 2.0, then no, it's not supported. (Actually, looking at the .NET 4.5 MSDN documentation for the property, it seems it's supported as of .Net Framework 2.0 SP1.)
If you are using Visual Studio 2010 or higher, I would ensure that you retarget your project to compile with the .Net Framework 2.0 (RTM) if that's what framework your application will be running against. I noticed that you specifically mentioned VS 2005. If you are using VS 2005, I don't believe that has any re-targeting capabilities (if memory serves me correctly); VS2005 by default compiles against .NET Framework 2.0. Here's where things get interesting: an installation of .NET Framework 3.5 has .NET Framework 2.0 SP1 and .NET Framework 3.0 SP1 as installation pre-requisites. So, if your machine has only .NET Framework 2.0 and you want to install .NET Framework 3.5, then your .NET Framework 2.0 will be upgraded to .NET Framework 2.0 SP1 (and additionally, .NET Framework 3.0 SP1 will also be installed).
So what does this mean for you? Well, if you compile your program on a machine on which .NET Framework 2.0 SP1 or higher is installed, your program will compile just fine. Furthermore, if you run the program on a machine running .NET Framework 2.0 SP1 or higher, it will also run just fine. However, if you take this same program and run it on a machine which contains only the vanilla .NET Framework 2.0, you will get the error you see above because that method/property is not supported in the libraries included with the .NET Framework 2.0.
The other side of the story is the part of the MSDN documentation that says that while FileDialog.CustomPlaces exists from .Net Framework 2.0 SP1 and onwards, and that while that version of the Framework may be installed on Windows XP, that on Windows XP calling the property has no effect (i.e. it's a null-op, not supported by the OS). So no error should occur, but you will also see that whatever you tried to add to the CustomPlaces collection would not show up when you run the application on Windows XP. Again, looking at the updated documentation as of .Net Framework 4.5.x (see the link above), it clearly states that the lowest supported client operating system platform supported is Windows Vista SP2. So in all likelihood, you're out of luck when it comes to Windows XP.
If you want to do an OS version check, I would advise you to do the following check:
if (Environment.OSVersion.Version.Major > 5 &&
Environment.OSVersion.Version.Minor >= 0 &&
Environment.OSVersion.ServicePack == "Service Pack 2")
{
// Add CustomPlace here...
}
Note that the check above will not allow you to add the FileDialog.CustomPlaces for Windows Server 2008 (even though it is supported—because through .NET, you're not able to check the ProductTypeID property). Furthermore, FileDialog.CustomPlaces is not supported on the Server Core mode of Windows until Windows Server 2008 R2 SP1 (but the code above will allow you to attempt to add the custom place, but like Windows XP, it will fail silently). In order to make a determination for these versions of Windows, you'll need to use a bit of PInvoke to access the Win32 API's GetVersionEx method and OSVERSIONINFOEX structure located in kernel32.dll as shown here and/or here.
However, generally speaking, it's not a good idea to do operating system version checks. They are notoriously difficult (especially with older operating systems). What you really need to do is to perform a .NET Framework version check. Your application apparently requires, at a minimum, .NET Framework 2.0 SP1. If you have an installer for your program, I would build in this check to your installer and optionally provide the ability to install the .NET Framework 2.0 SP1 as part of the installation of your program.
If you're not using an installer to distribute your program, then you should perform a .NET Framework version check in your application prior to attempting to add the FileSystemCustomPlace to the CustomPlaces collection to prevent the error from occurring; however, doing so will require your users with versions of Windows Vista and later to run the application with elevated permissions. Aaron Stebner has a great blog post on how to determine the .NET Framework installations that are available on your machine with example code. There is also a C# implementation of this code provided by a CodeProject.com user here.
Related
I want to understand how does the life-cycle of c# works ? Is it tied to the supported operating system ? For e.g C# 5.0 has Windows 2000, Windows 7, Windows 98, Windows Server 2003, Windows Server 2008, Windows Vista, Windows XP as supported OS. And looking into MS' life-cycle support it looks ALL of them have already reach the end-of-file. So, is fair to say then that C# 5.0 is also coming to EOL ?
The Microsoft C# compiler is part of the .NET Framework, and the life cycle of the .NET Framework is, as you correctly assume, tied to the operating systems that it is part of.
Details can be found here:
https://support.microsoft.com/en-us/help/17455/lifecycle-faq-net-framework
The Microsoft C# 5.0 compiler is part of the .NET Framework 4.5. Since the support for .NET 4.5 and 4.5.1 ended on Jan. 12, 2016, an upgrade to .NET 4.5.2 is required to continue receiving technical support.
However, since newer versions of the C# compiler can target earlier versions of the .NET framework, the question is moot - there is simply no convincing reason to use the MS C# 5.0 compiler instead of, for example, the current version of the .NET compiler platform (Roslyn).
i am developing WPF application in visual studio and using .NET 3.5.
does the application fits Windows7 and Windows8 OS with no .NET framework additional installation?
do i need to add .NET 3.5 installation to setup project?
In Windows 7 .NET framework 3.5 is part of the operating system so all machines should have it.
In Windows 8 or windows 8.1 .NET framework 3.5 is NOT automatically installed (though all machines that are upgraded from win 7 -> win 8 should have it).
To run apps that require the .NET Framework 3.5 on Windows 8 or later, you must enable version 3.5 on your computer. There are two ways you can do this: by installing or running an app that requires the .NET Framework 3.5 (that is, by installing the .NET Framework 3.5 on demand), or by enabling the .NET Framework 3.5 in Control Panel. Both options require an Internet connection.
If an app requires the .NET Framework 3.5, but doesn't find that version enabled on your computer, it displays a message box, either during installation, or when you run the app for the first time. In the message box, choose Install this feature to enable the .NET Framework 3.5.
The above require an internet connection. If this is not possible you will have to include the .exe files of .NET 3.5 in your distribution
however as MSDN states:
The .NET Framework 4.5 and its point releases are backward-compatible
with apps that were built with earlier versions of the .NET Framework.
In other words, apps and components built with previous versions will
work without modification on the .NET Framework 4.5. However, by
default, apps run on the version of the common language runtime for
which they were developed, so you may have to provide a configuration
file to enable your app to run on the .NET Framework 4.5
So build your project for 3.5 and just deploy it to windows 8 machines. It should run, but its not the "best" environment for the app. The "best" would be to have .NET 3.5 installed.
Sharepoint 2010 has a version check in single place (also starting from some update WSS 3.0 has such check also):
...
Version version = Environment.Version;
if (version.Major > 2)
{
...
throw new PlatformNotSupportedException(#string);
I know, that I should not do this, but just out of curiosity - is it possible to overcome this without writing huge proxy?
Just out of curiosity, wondering if it is possible to do any of these:
adjust this check in sharepoint's dll at runtime to pass (class, that is using it is sealed and internal, if you're curious, it is Microsoft.SharePoint.Administration.SPConfigurationDatabase class in Microsoft.Sharepoint.dll)
temporary override Environment.Version return value, something like:
using (new EnvironmentVersionOverride("2.0")) { ... }
some other way?
Update:
Environment.Version decompiled source:
public static Version Version
{
get
{
return new Version("4.0.30319.18444");
}
}
First and foremost, WSS 3.0/Share Point 2010 were created such that the engineers at Microsoft knew exactly which version of the Common Language Runtime (CLR) WSS 3.0/Share Point 2010 would run against without errors.
As alluded to above, Environment.Version returns the CLR version (not the .NET Framework Version) currently loaded in your process. There is no way to "fake" or "proxy" this value. If you are running SharePoint on a Windows 7, Windows Server 2008, or Windows Server 2008 R2 machine, then the CLR 2.0 is automatically installed (I'm not sure about Windows 8 or Windows Server 2012, though).
It sounds to me like you need to make sure that the Application Pool in IIS under which the Share Point 2010 (or WSS 3.0) website is running is using .Net Framework Version 2.0.50727 (which implies the use of CLR 2.0). As stated here, Share Point 2010 will simply refuse to run when the website for it is using an Application Pool targeting the .NET Framework 4.0.
If the machine running Share Point 2010 / WSS 3.0 does not have the .NET Framework 3.5 SP1 installed (which includes CLR 2.0), installing that and ensuring the Application Pool settings are correct should resolve your issue and you won't need to "proxy" the value of Environment.Version.
If you're trying to create a library for use by Share Point 2010, then ensure that your library is targeting .NET Framework 3.5.
Hello friends i need an explanation regarding .NET framework pre-requisite while installing the published application in the target machine.
As java is downward compatible, by which i mean that if i have installed java v1.6 and if the application is developed using java v1.5 (i also mean that only classes and packages available in 1.5 are used to build the appln.)
I am sure that the application developed will definitely run by installing the latest or higher versions of jre or j2se.
Similarly in the case of .NET platform suppose if i develop my application using .NET framework 3.5 and in the target machine i have installed .NET framework 4.0 (the latest) even then it prompts to install the .NET framework 3.5 why is this so?
The real time example is i have downloaded and tried installing MySQL workbench and also installed .NET framework 4.0 But it still asks to install the .NET framework 3.5 before running the MySQL installation.
My question is does .NET framework is downward compatible as java or .NET?
Version Compatibility in the .NET Framework:
The .NET Framework 4 is
backward-compatible with applications
that were built with the .NET
Framework versions 1.1, 2.0, 3.0, and
3.5. In other words, applications and components built with previous
versions of the .NET Framework will
work on the .NET Framework 4.
However, in practice, this
compatibility can be broken by
seemingly inconsequential changes in
the .NET Framework and changes in
programming techniques. For example,
performance improvements in the .NET
Framework 4 can expose a race
condition that did not occur on
earlier versions. Similarly, using a
hard-coded path to .NET Framework
assemblies, performing an equality
comparison with a particular version
of the .NET Framework, and getting the
value of a private field by using
reflection are not backward-compatible
practices. In addition, each version
of the .NET Framework includes bug
fixes and security-related changes
that can affect the compatibility of
some applications and components.
If your application or component does
not work as expected on the .NET
Framework 4, use the following
checklists.
For .NET Framework 2.0, 3.0, and 3.5 applications:
Check .NET Framework 4 Migration
Issues for any changes that might
affect your application and apply the
workaround described.
If you are recompiling existing source
code to run on the .NET Framework 4,
or if you are developing a new version
of an application or component that
targets .NET Framework 4 from an
existing source code base, check
What's Obsolete in the .NET Framework
for obsolete types and members, and
apply the workaround described.
(Previously compiled code will
continue to run against types and
members that have been marked as
obsolete.)
If you determine that a change in the
.NET Framework 4 has broken your
application, check the Runtime
Settings Schema to determine whether
you can use a runtime setting in your
application configuration file to
restore the previous behavior.
If you encounter an issue that is not
documented, file a Microsoft Connect
bug and contact netfxcf#microsoft.com
with the bug number.
Yes, .Net 4 framework is backwards compatible with applications built on previous versions of .Net. You can see this link on MSDN for more info.
If you have .Net 3.5 or .Net 4 installed and a third party still requires either (or and older version) then the installer is not checking the correct prerequisite install conditions.
If I compile a simple(no additional libraries or assemblies) c# application, can I assume it will run on any new windows 7 machine natively or do I have to worry about end users having .Net or other libraries installed?
Windows 7 includes the .NET Framework 3.5.1 as an OS component.
This means you will get:
.NET Framework 2.0 SP2
3.0 SP2
3.5 SP1
some post 3.5 SP1 bug fixes
However, if you're using newer versions of .NET, and if you're using libraries that don't get shipped with the above, then you still need to consider packaging these up in an MSI/installer.
This page on Wikipedia has a good summary:
http://en.wikipedia.org/wiki/.NET_Framework#Versions
If this is anything more than a "quick and dirty" app, or unless you work in an area where you know exactly what the target machines look like (i.e. a corporate environment with a locked down OS image) then I'd suggest you look at building an installer and deal with pulling down the pre-requisites as appropriate. (WiX is my recommended way of doing that).
http://wix.sourceforge.net/
And WiX questions are tagged here on SO...
https://stackoverflow.com/tags/wix/
Windows 7 comes preinstalled with .NET 3.5.1 which includes 3.5 SP1, so unless you need features of .NET 4 it should work just fine.
Windows 7 ships with .Net 3.5, so, if you this .net version or lower, your application should be able to run on any Windows 7 installation
You need the appropriate .Net framework installed to match what your C# program was written with. If you don't have the correct framework, download it from microsoft.com.