I'm working with a C# sample application (taken from here : http://www.piccoder.co.uk/content/view/42/26/1/4/)
The sample app and the source code are available in the .zip file.
When I run the app in Windows XP, it is working correctly.
But the same app, when I run in Windows 7, it is not working correctly. You can try run the WindowsApplication3.exe file in the /bin directory, and try to do the addition of two number there. The result will always be zero (in windows 7)
I've been using Visual Studio 2008 (in my Windows 7 machine) to modify and build the source code, and run the output app in Windows XP machine for testing purposes. I hope I can test it on Windows 7 machine directly. Can someone take a look at the source code and guide me if there were anything to be modified or added since this sample source code is quite an old code.
Thank you!
The problem most probably has nothing to do with C# or the .Net framework. It's likely a failure in the communication with the USB driver. The drivers model has changed drastically between XP and Vista/Win7 and the USB wrapper library most likely assumes the XP driver model.
Related
I have a portable app that isn't stealth. And by stealth, I mean:
"Stealth" means when an application is launched, used and terminated properly, it does not leave behind any entries in the registry or filesystem.
My app runs under .Net Framework 4.6.1 and leaves behind a log file under the folder:
%AppData%\Local\Microsoft\CLR_v4.0_32\UsageLogs\ [App Name].exe.log
Who is creating this log file?
Is there any way to avoid the creation (without breaking the app)?
What's the purpose of this log?
With Windows 8 (.NET 4.5), a new NGen mode: "Auto NGen" has been
introduced. Basically, the .NET runtime generates usage logs for
managed applications. Source
Every time the application run it creates a new type of logs called
“Assembly Usage Logs” in the AppData windows directory.
Source
On my research I found out mostly that it only does this job on Windows 8+.
But in this source it says also on Windows Server 2012, but I have tried it on a Windows Server 2012 R2 and could NOT reproduce it!
I did not find a way to disable this, one solution could be to target a lower .net Framework within our application.
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 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.
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 have created an application in VS C# Express 2008 using Windows 7 as my OS. It runs perfectly fine on other W7 machines, but when we try and deploy it on a machine with XP it doesn't even run. I just get the usual "Application needs to be terminated" error message. The app was built using .NET 3.5 and all the machines have at least 3.5 installed. Is there anything that I may be able to do to get the program running in previous versions? Thanks in advance for your help.
Updated Info. The machines all use x86 32-bit OS, either XP SP3 or W7, so I don't think that there is a huge need for checks for 64-bit issues. The application itself is loading images into an image list and adding in an image when it finds a break in the file names. (eg. There are 4 images in a folder, 1-3 and 5, what the application does is iterates through each image name and the minute it sees that image 4 is missing, it adds a placeholder image and labels it image 4.)
You should set up an UnhandledExceptionEventHandler so that you can log information about the current state of your application and the exception information. It isn't going to stop your application from crashing, but it will give you more information about what happened and make it easier on your end user to give you what you need to know when the application crashes.
This article give a good description of how to do that.
First you must be sure that .Net Framework 3.5 is installed on your Windows XP machine. If everything is OK, then you should check if you are using "3rd party dlls as reference" and validate their existence and correct versions on your Windows XP machine.
Probably this can help.
Log the exception which is thrown by the application so that you can fix it.
Not a lot of info but some things to check:
Make sure you have the latest patches on XP and SP release
Maybe you need to run the program as administrator - are you logging in as admin
Have you checked the windows appliation error log to see if there is anything there that might be helpful