So I have an app (tool) that uses .NET 3.0. When run on a machine that only has .NET 2.0 (like the default Server 2008 R2 install) it crashes miserably.
What I've seen so far is that people are using a shunt that will first check the .NET version.
Is there a way to build it or add some manifest somehow so that the user is warned of this problem (and hopefully be prompted to install .NET)?
I know this can be solved by an installer, but I have requirements that need it to be a standalone executable. (Ok this is hard to explain, but it's related to the a device driver. The tool comes with the driver, but the user shouldn't be forced to install .NET 3.0 if they won't use the tool.)
I just need to stop at the point where a cryptic "application has failed with exception 0xe0434f4d" message and at the very least give the user some idea of what happened.
Have not tested this, but this article about framework detection tells how you could detect the framework version from code. I'm not sure where your application fails and if injecting checks like this could solve your problem, but if you cannot use this in your app, you could perhaps create a small "starter app" in old .net 2.0 that performs these checks and then either tells the user to upgrade or starts your "real" app?
As I said, haven't tested this approach, it's just off the top of my mind.
This never makes any sense to me. Where are you going to stop? Are you going to make sure as well that the user doesn't install it on Windows 98? That the machine has enough RAM? That the user account has enough privileges?
Software vendors publish system requirements. You always quote the lowest supported Windows version, minimum amount of RAM, required disk space, minimum browser version, etc. Minimum .NET framework version belongs in that list too. The intention of this list is clear: don't expect it to work properly if you don't meet the requirements. If you do it anyway, it is your problem, not mine.
This is different for a consumer-level app. But when you install to Windows 2008 server, you are not writing a consumer app.
Related
I have a very limited knowledge for Linux/Ubuntu platform.
There are some requirements coming though for me to deploy a version of our desktop application on either of the above platforms.
With the context, I have the following queries in my mind:
Could the same code can run on windows using the MONO/MONO IDE and I can compile the output to the OS specific?
OR assuming there are certain changes I must make to run them on different OS, what could be the best way to deploy it on Linux/Ubuntu?
OR Is it possible to keep the same code under windows development, however can be deployed on Linux/Unix environment?
SQL wont work on Unix so you'll need to convert that first.
Yes thats the way to go.
You need to do step 1 to work out if there are required changes specific to OS's.
Assuming that everything required by the assembly is supported by Mono, you shouldn't have to do anything - it should already be binary compatible. That's one of the points of IL :)
If you do find some things that aren't supported by Mono, suggest you have a Unix branch of code.
I would like the next update of our C# application to be the last one targeting the 2.0 Framework, and the following one to target framework 3.5. The application will be installed on a share on the client's server and accessed from a load of client machines which will need to have Framework 3.5 installed, hence all the users will receive the update at the same time.
I would like to get some way of pre-installing 3.5 before it is actually needed. My real reason for this, is that the framework install can take a long time and I don't like the idea of everyone being idle and the same time until the installation is complete.
What I was thinking was adding background code in our next update which checks to see if 3.5 is installed and that the DotnetFx35.exe is available and periodically offer to user the chance to install it (maybe by starting \\server\share\dotnetfx35.exe /q /norestart.)
I do not want to force an install via a group policy update as there will be machines that do not run our application and hence will not need the new Framework.
Does anyone have any experience with anything like this and/or any tips before I start experimenting?
This might not be the answer you're want, but its a point worth mentioning, I've had personal experience with the framework 3.5 not installing as it should on certain client machines, and the installer app, doesn't give any feedback on errors.
If you have a lot of client machines, just brace yourself for the possibility that some of these machines will have some install compatibility issues with framework 3.5 and you'll need to check the install logs or event viewer for more information.
You can have your clients install .NET 3.5 SP1 whenever they like - it is completely backward-compatible.
If it was me, I'd create a list of the client machines that are going to use the new app and just go around installing it. It would need to be done sooner or later anyway.
This question already has answers here:
Is Mono ready for prime time? [closed]
(17 answers)
Closed 8 years ago.
C# looks great because it is a compiled language which seems to run quite well without too much CPU and does not consume too much memory. And StackOverflow and ServerFault are good examples of an MVC/.Net/C# stack that scales.
C# is also interesting because despite being compiled, it still has a lot of advanced features as a language only found on slower interpreted language.
My server being Linux only (Ubuntu 8.04 LTS), I am wondering if installing Mono in place of the .Net framework is a good idea for production use.
I currently do not have any existing applications using .Net but I am interested in using existing frameworks (like MS MVC).
Stable enough and fast enough to do what?
It will have different levels of stability and performance depending on what you want to do, I'm sure. For example, one of my Protocol Buffers unit tests (which uses Rhino.Mocks) manages to make the Mono VM abort with an assertion error - but I have no idea (currently) of whether that would affect anything else I'm doing, or whether it's just related to the form of proxying being used.
I suggest you try it and see.
ASP.Net MVC is now open source. That it is now integrated into MonoDevelop via an add in would suggest that you are likely to get things working.
Given the very new status of this you should expect issues. This blog should be a reasonable starting point for you.
Remember that many ASP.Net MVC tutorials assume you have a sql server back end, this is unlikely to be feasible (given your question) so bear that in mind.
You'll have to judge it on a feature basis. At my current customer we're running a high-volume document processing and delivery system written in .NET 3.5. We have a Linux server that runs Mono with .NET components that take care of the delivery of documents to the outside world, e.g. through FTP. That runs fine in production.
We did run into a problem with the Mono implementation of the .NET FTP component, which forced us to look for other third party .NET components, which solved the problem. So you might run into things like these. But in our case: once we got it to work, it worked just fine and stable.
I think that Mono is REALLY stable and complete.
It brings .NET to *nix World.
In my company I'm leading a project aimed to build an automated machine. This machine is built by different devices that need to be governed using a serial interface (RS232).
The machine exposes a touch screen for user interaction.
One of my responsibilities is to project the logic of the system beyond the GUI application.
I've chose Mono (used for presentation layer) also to build a custom middleware that runs the application business logic.
This middleware is some sort of application server and it's executed in Ubuntu 10.04 LTS.
For now all the system is an advanced prototype, but also the final product will keep its heart in the couple Linux/Mono.
I hope that these considerations could be useful for you.
Regards,
Giacomo
as i had read on mono project wait for MONO 3.0 it will solve the main problem in mono means memory leakages and garbage collectors so before 3.0 we can't say it as stable but it is a life line for developers like us who want to develop platform independent s/w with dot net.
I have an C# application that needs to list a directory ( Directory.GetFiles() ) and also to access one of the files returned. If I run the application locally it doesnt have problem access the network location or the local locations, if I run it from a network share then I get a security exception thrown when accessing the shares.
I found out why this is happening:
http://blogs.msdn.com/shawnfa/archive/2003/06/20/57023.aspx
However the solutions seem... impractical unless I am misunderstanding it.
1) I can not use the code ( hardly an option )
2) Sign the assemblies and then have whoever is going to use it configure .NET policies to allow it? ( This relies on the person whos going to use it to change one of their policies which I have no say in ??)
3) Change the policy to allow full trust for everything on localintranet ( Not recommended or even possible in my case )
Am I missing something here, none of those choices seem optimal for a stand alone application being pushed onto a network I have no say in. I would have thought doing something as relatively simple as running an application from a network share to list files in a directory wouldnt have required such crazy hoops to jump through to make it work.
Anyone have any thoughts on what I could do in this situation?
These threads will answer you question, I think:
Why does my .NET application crash when run from a network drive?
Running a C# exe file
This behaviour is changed in .NET Framework 3.5 SP1, where it defaults to allowing programs running off network shares.
And yes, it does not feel very practical, but there is unfortunately not much to do about that...
I would deploy it as a ClickOnce app ("Publish" in VS2008 etc). ClickOnce can be located on a network share - you just run the .application instead of the .exe; this then works with none of the security issues with running it directly, and it'll work all the way back to .NET 2.0.
This problem should no longer exists when you require your users to upgrade to .NET Framework 3.5 SP1. See the following blog article on that topic:
.NET Framework 3.5 SP1 Allows managed code to be launched from a network share!
I've been looking for this information for my commercial desktop product, with no avail.
Specifically, what I'm look for, is deployment statistics of the .NET framework for end-users (both granny "I'm just browsing the internet" XP, and high-end users, if possible), and in the commercial/business sector.
Edit: Other than the data points below, here's an interesting blog post about .NET deployment rates.
Some statistics from 2005 I found at Scott Wiltamuth's blog (you can be sure these numbers are much higher now):
More than 120M copies of the .NET Framework have been downloaded and installed using either Microsoft downloads or Windows Update
More than 85% of new consumer PCs sold in 2004 had the .NET Framework installed
More than 58% of business PCs have the .NET Framework preinstalled or preloaded
Every new HP consumer imaging device (printer/scanner/camera) will install the .NET Framework if it’s not already there – that’s 3M units per year
Every new Microsoft IntelliPoint mouse software CD ships with the .NET Framework
It is also worth pointing out that Vista and Windows Server 2008 both ship with the .NET Framework. XP gets it via Windows Update.
It depends a lot on which version of the framework you are targeting. I believe 1.1 (and even 2.0) are widely deployed. The later versions are not.
You should also visit this site for some very good information on .Net Framework Deployment: http://www.hanselman.com/smallestdotnet/
I don't have any hard numbers, but these days, it is pretty safe to assume most Windows XP and Vista users have at least .NET 2.0. I believe this was actually dropped via Windows Update for XP, and Vista came with at least 2.0 (apparently with 3.0 as pointed out in the comments to this answer).
I needed that same kind of information at my last job, where I was attempting to convince my manager to allow .NET development. The customer base was primarily dial-up users, so requiring a 20+ MB download was a tough sell. Unfortunately, I wasn't able to find any sort of statistics, either from Microsoft or from a research firm.
What I was able to get, however, was web analytics from the company's home page. .NET inserts its version number into the User Agent field, which I was able to log using our analytics package. From there, some Excel gruntwork was able to give me a rough idea of how many customers already had .NET installed, and which version(s).
Unfortunately that won't help you answer the broader question of deployment rates across multiple demographics, but it might be a useful technique for a single customer base.