I have a huge problem on one of my winform application. Someone who use my application works on windows 7 64bits and apparently it directly crashes when the application is launching.
My application works correctly on :
-Windows XP
-Windows Vista
-Windows 7 (32bits).
I developped the application on Visual C# express 2005 (.NET 2.0).
I am wondering if there is anything I can do to recompile my application to make it work on windows 7 64bits.
I am sorry, I have no access to the computer of the person (so I can't check, exception or anything like that). I am pretty sure that this issue is known that's why I'm asking you right now.
Does anyone have an idea ?
Thank you by advance for your Help
Regards,
Joze
In project properties setting window, select tab Build and change Platform target to X86. Republish..
EDIT: to the down-voter
By doing this Windows will know your program is designed for X86 use and will install it accordingly. (I've done this with Clickonce, and it works..)
Likly you use some interop x86 DLL or COM object. Try setting for your executable Target Platform x86 (not Any CPU as it is by default).
Do you use any unmanaged (com) components in your application?
If so, most likely you're including the 32bit version. If that's the case, you will have to compile 2 different versions of your program, one including the 32bit components, and the other including the 64bit components.
If that's not the case, it means you're using some platform specific code somewhere. More details about your application could help clarify the problem.
Related
Would it be possible to code and compile C#, on a Windows 8 Tablet (WinRT) (the ARM processor edition)?
Basically it comes down to this:
Is there a C# compiler that runs on ARM?
Is there and IDE that can run in WinRT?
If the above is true, I don't see any issue, but I currently can't find if the C# compiler runs on ARM (only a lot of posts about compiling for ARM). I've also looked at SharpDevelop, and found that their source code compiles for "Any CPU", which according to this post: Windows RT and c#, means that it'll run on ARM.
Sharpdevelop however requires .NET 4.0 "Full" runtime, which I couldn't find if WinRT has or not. I'm betting it doesn't, as WinRT is supposed to be a really lightweight edition of Windows.
As a sidenote, I know that Windows tablets will come in two editions, one for ARM and one for classic processors. The classic processors will run a normal Windows 8 edition, which means it can run all the native applications. Compiling C# wouldn't be an issue here - so the question is rather, can I do the same on ARM?
This would be awesome for travelling and trying out new ideas quickly.
Currently: no, and no.
It would certainly be possible to build a Windows Store app that contains an IDE and a C# compiler. However, you would not be able to run any programs built using such an app. Windows Store apps run with reduced privileges in a sandbox. In this sandbox, the CLR will only load system assemblies and assemblies contained in the app package. The app package is immutable and cannot be modified at runtime.
Actually, the .Net framework on the surface includes csc.exe, the Csharp compiler.
I've gotten code to compile, but WinRt doesn't seem to like it being run without proper signing.
The IDE won't happen for a while, not yet at least. I'm sure that with proper signing, it is possible to run a compiled executable.
Or the other guy might be right and it isn't just an issue of signing.
I've ported SharpDevelop to run on unlocked Windows RT devices, it works at least for C# Windows Forms apps. http://chentiangemalc.wordpress.com/2013/03/18/sharpdevelop-rt-edition-beta-code-windows-forms-directly-on-windows-rt/
I'm developing an application for a pos-pc running windows xp, this application is based on .NET framework 4 and use wpf for the UI.
I need to increase the performance of such application, I've read about ngen for generate native image but I don't understand very well how it works and how to use it.
Any tip, link, tutorial about ngen will be much appreciated.
I need to create a lightweight version of windows xp capable of running .NET framework 4 and use some COM object but i don't know what I can remove from the XP installer (using nLite).
I've tried Windows embedded 7 standard but the Intel gma driver are not compatible and i can't install it.
Thanks
check this one: Improving WPF applications startup time
in short, ngen is an utility that compiles the IL code generated by Visual Studio build process into machine dependent code which does not require the JIT to compile IL anymore at runtime.
How can ngen be relevant for a POS? DOnt getm e right, but this handles startup performance and POS get turned on once in the morning if at all (i.e. if they dont stay up overnight). If you ahve a WPF performacne issue may I suggest you fix those, and dont dabble with native image gneration?
Does the machine have network access? Perhaps moving business logic from the client to a service on the network would improve the performance, so that the client becomes simply a UI shell for the service.
I have an app that I wrote using C# .NET 4.0 in Visual Studio 2010 on my Windows 7 Ultimate machine. This app works fine on both Vista and other Windows 7 computers, but whenever someone running Windows XP tries to run it it crashes.
In order to reproduce this I've tried running it on my Win XP VMWare machine and it crashes for me in there. Unfortunately it doesn't give me any specific error, just informing me that the program has crashed and needs to close.
One other user sent me the following:
Run-time error '339'
Component 'vbalSGrid6.ocx' or one of its dependencies not correctly registered: a file is missing or invalid.
Code 0xe0434352
Flags 0x00000001
I don't get that particular bit when I try to run it on my Virtual XP machine, and I also made sure to install .NET 4.0 on there.
What could be causing this, and why won't the app run in XP if the .NET 4 framework is supported for XP?
Components used in the program: DataGridView, ComboBox, Buttons, Labels, LinkLabel, NewtonSoft's JSON parser, and that's about it.
I am baffled and have utterly no idea where to start. Ideas?
UPDATE: Hmm, tried running my other recently created application on XP and it loaded fine. The only major difference (in the components I used anyway) between the two is my use of NewtonSoft's JSON library, which I actually think is a .NET 3.5 component.
UPDATE 2: Just for kicks I tried running the program on my Wind7 machine in "Windows XP SP3" compatibility mode and it ran fine. Of course, I have no idea just how closely the "compatibility mode" emulates a true XP SP3 environment, but I figured I'd give ya'll the info anyway.
¡¡ IT WAS THE APPLICATION ICON !!
I kept noticing that the module it referenced in the error it gave me was system.drawing which I thought was odd. I figured perhaps the PictureBox I was using was causing the issue, so I tried disabling everything to do with that, to no avail.
I had my business partner set up his XP box so that we'd have another machine to test with aside from my VMWare XP box just in case there was some odd issue with it.
After he got it set up and the app copied over he said "The icons look like DOS ones" and I had a eureka moment.
I was using .PNG's as the icons because they support transparencies and whatnot, but XP doens't natively support them. So when the app was copied to the desktop it just used a generic icon for it, and when the application was run it crashed because XP doesn't know how to render a .PNG.
Try using the Fusion Log Viewer to debug startup errors in .NET applications.
Scott Hanselman has written a nice howto along with links to further resources if you need to go deeper.
Are we sure this is some wierd .NET compatibility issue or just a run of the mill bad installer/deployment problem?
Here's one user who has that error message because the OCX DLL was copied to System32 with a shortname. Renaming the DLL to the correct name and running RegSvr32 resolved his problem.
Do you have an installer? Have you correctly identified all of your managed and unmanaged dependencies and properly authored them into your installer?
http://forums.elmsoftware.com/forum_posts.asp?TID=119
I am working with c# windows form application and i am using mysql as backend. i created setup for my project by giving target platform property as x64. when i install my application in windows 7 64bit OS it installed perfectly without error. but when i open the installed application it cant open ,its shows "Windows closing the application". what is the solution for my problem. Eventhough i didnt install mysql driver.
I have another c# windows form application with DirectX without have any backend, this application also have same problem
Thanks in Advance
Here are the diagnosis steps I'd go through:
Check the event log. If the CLR has failed to load your application to start with, there may be something in there.
Try using the Fusion Log Viewer to see what's happening in terms of assembly binding.
Does the MySQL driver you're using have separate 32 and 64 bit DLLs, and are you sure you're installing the right one?
Are you able to test this without going through a full installation (i.e. build and run on a Win7 x64 box without the installer part)?
Does it still fail if you build for "Any CPU"? Or is there some specific reason why you can't do that?
Does it fail if you build for x86, which should still work fine on an x64 box? (Unless you really need to take advantage of lots of memory in your app, there can be some performance benefits to running the x86 CLR, particularly in terms of memory as every reference is half the size.)
If you create a small "test app" which doesn't use MySQL, does that fail?
Can you write a tiny console application which does use MySQL, and make that fail, thus showing a minimal amount of "user" code required to provoke the failure?
Chances are that the source of your problem is that you application is running as a 64 bit process but it has some dependency on a component that is only available in 32 bit. This is not unexpected when you depend on DirectX. MySQL I'm not so sure about.
When you build your project you decide which platform you want to target. You do that in the settings for your project in Visual Studio.
Right click on the project the in solution explorer and select Properties from the menu. It is important that you right-click on the project that creates your application and not for instance a setup project.
On the left side of the window displaying the settings you have some tabs. Select the second tab named Build.
There is list box named Platform target. This is where you determine what platform to target.
You have four choices:
Any CPU: If you choose this your application will run as the "native bitness" of your host operating system. On 64 bit Windows your application will run as 64 bit. Do not select this if you have a dependency on a component that is only available in 32 bit. If that is the case and you select this your application will run fine on 32 bit Windows but will fail on 64 bit Windows. That is the symptom you are experiencing.
x86: If you choose this your application will always run in 32 bit. Select this if you have a dependency on a component that is only available in 32 bit.
x64: If you choose this your application will always run in 64 bit and will refuse to run on 32 bit Windows. That is probably not what you intend.
Itanium: This is for another processor architecture.
I am developing a WPF application where the 3D part is handled by DirectX 9 (a lot of 3d that did not run fast enough using WPF).
The problem is the application is released with "Any CPU" as configuration and when a user runs it on a 64 bit windows, the direcX part crashes (System.BadImageFormatException). Apparently the dlls included for the directX part is not usable on a 64 bit windows.
This has happened with some other 3:rd part dlls that we use in our application but this we have solved by changing the dlls in runtime to the ones built for x64 if the user are running on a 64 bit windows machine. Do any of you know where I can find DirectX 9 dlls for x64? If they exist at all.
The ones I need are:
Microsoft.DirectX.Direct3D
Microsoft.DirectX.Direct3DX
Microsoft.DirectX
If they do not exist, can the problem be solved in some other way? I cannot change the configuration to x86 because the application is released via ClickOnce and a change of configuration make ClickOnce stop working (the configuration is included in the ClickOnce key)
Let me add that the I am using a Winforms part hosted by the WPF application and that the winforms part is using the DirectX dlls I am asking about. This was a much better and faster way of presenting a lot of 3D meshes in WPF than to use WPF:s 3D. Unfortunately this problem occurred instead.
The DLL's you need are for Managed DirectX. Unfortunately Microsoft no longer supports Managed DirectX and it's successor, XNA does not support 64bit either.
SlimDX is an open source alternative to Managed DirectX, and it supports 64bit. The other option is to write the DirectX code in unmanaged C++.
You can set your WPF application to only run as a 32-bit app. Post your ClickOnce problem as another SO question. This is probably your best option.
Project Properties -> Build -> Platform Target -> x86