Learning C# as I go along with managing an existing project given to me. I've noticed there seem to be deployment issues when I build from my windows 10 machine and set up the application on a user's Windows7 machine
Issues such as:
-Getting null pointer errors
-when saving word docs automatically, instead a save dialog box appears
I cannot for the life of me recreate the issues on my machine.
From what I see,
I use Windows 10 64bit with 32bit Microsoft Office
They use Windows 7 64bit with 32bit Microsoft office
We both have .NET v3, v3.5, v4.0.3... and the project is in v4
I can't help but think it is OS related issue I need to account for but I don't know whether I can trust this due to my lack of experience
Can anyone give some advice
My current plan is, since the users are not very accessible, I will try and get a laptop that replicates theirs. Then, if I can recreate the error on there, then i will install visual studio remote debugger and try to attach this external process and debug from my side. Mostly this is my only plan which is a long shot at best
It sounds like you're dealing with Office automation/addins. I would imagine that the version of Office is very important -- not just 32 bit vs 64 bit, but the specific build and version of Office/Word.
Recreating the error is key, as you suspect. Try setting up a Windows 7 VM on your PC with the same environment that the users have. This will make it easier for you to reproduce and debug the issue.
You also need to know the exact sequence of steps that causes the error, and if possible, you will need a copy of the document the user was working on.
Related
Context
For a bit more context, the company I work for made an Access vb.net application that runs inside MS Access. They wanted to upgrade and create a C# WPF frontend for it. This works great except for the fact that when I installed the application and downloaded the [dummyDB].accdb (32-bits 2016) the application immediatly broke with the error :
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.
I then installed the 2010 AccessDataBaseEngine from Microsoft and a new error apeared:
This Database file requires a newer version of Access
Naturally I went back to Microsoft, downloaded and installed the 2016 x64 (my system is 64-bits) and tried again.
Sadly we we're back to the first error. So i tried to install the 2016 32-bits AccessDataBaseEngine but ran into the problem that I had already installed 64-bits office products. (I also uninstalled all the previous 32-bit AccessDataseEngines)
We of course don't want users to reinstall all their Office products just to use our application.
Question
Is there a NugetPackage of somesort that we could use so the customer can interact with the AccessDatabase out of the box?
If not, is there anyway to make it so they wouldn't have to reinstall all of their Office products?
ps. Different DataBase files 32-bit and 64-bit for users is also not an option because different users with most likely different systems will have to access the same database file.
I don't know if I'm being completely oblivious here, but any help would be greatly appreciated
Application info:
WPF application (.Net Framework 4.7.2)
Build Target : anyCPU
Is there a NugetPackage of somesort that we could use so the customer can interact with the AccessDatabase out of the box
No, not as far as I know.
If not, is there anyway to make it so they wouldn't have to reinstall all of their Office products?
You could write an wrapper that handles both 32 and 64 bit versions of the access driver. I.e. if the installed driver is the same platform as your program you can just continue as usual. If it is another platform you need to start a new process with the correct platform, and delegate all the database work to this process. If your process is anyCPU and is run on 64-bit windows the actual platform will depend on the "prefer 32-bit" flag.
Another alternative is to build both 32 and 64 bit versions of your entire application and run the one matching the office installation. This might be easier, but might not work if you have other platform specific dependencies.
This all assumes that office is already installed, if it is not you can just deploy the stand alone ace driver (i.e. AccessDataBaseEngine) with the correct bittness. The database file itself is platform agnostic and can be accessed by either 32 or 64 bit processes. It is the driver that needs to be of the correct version.
Note that Access is kind of difficult to work with and rather error prone. If this product is intended to be long lived I would suggest migrating to something better sooner rather than later. SqlLite is a popular embedded database engine that could be an alternative.
I have a .NET application that regularly works on all the machines with .NET installed.
When I try to launch it on a PC with no .NET framework installed this happens:
it opens, i can change tab (my app has 4 tabs), it reads the computer IP without any problem, but then crashes somewhere when it receives a message from another terminal (i have a terminal that communicates with the PC via ETH-TCP/IP).
The message I get is just:
DESCRIPTION: stopped working.
The big deal is that I cannot debug it because if I install the .NET framework it magically works like a charm.
Obviously I'm asking this because we prefer not to install .NET on all the machines in the office (they run different Windows versions and plenty of them don't have the .NET installed).
My question can be similar to this one, but in my case the .exe starts (as I explained above).. the crash comes when I start the communication between the PC and the terminal.
Anybody has a hint for my problem? Thank you
EDIT : thank you for the answers, in the end I decided to do Remote Debugging by running the app on a virtual machine with no .NET at all. Now, when it crashes, I can catch the bad instructions inside VS2010 installed on the host machine.
Btw, the problem was on a .dll that couldn't be loaded
You must have the .NET Framework installed on a machine in order to run a .NET application. The .NET Framework is both a runtime and the SDK, not just an SDK. All versions beyond Windows XP come with some version of the .NET Framework installed.
If you are saying that installing Visual Studio corrects the issue (which is what the question you linked to describes), that is a different problem altogether. Unfortunately, your question doesn't provide enough information to troubleshoot it. You can check the Event Viewer on the machine experiencing the issue, then look for two errors next to each other in the Application event log. One of these errors will contain exception detail, which will aid us (or you) in tracking down the problem.
Alright, so I've got a Windows service that has a FileSystemWatcher that watches an output folder for some Visual FoxPro database files. And it leverages the VFPOLEDB.1 provider to read those files. I cannot go away from this provider because it's being used in production.
However, I've never had to support this application before so that's why my development box isn't setup for it. Here is my environment:
Windows 7 x64
Visual Studio 2005
.NET 2.0 Windows service
so, when I first started getting the error I figured I just didn't have the provider at all, and I was right. So, I downloaded and installed it from here.
I then proceeded to drop the files in the folder again, but I got the same error.
I figured because it's an x64 machine I might be experiencing problems with it getting registered since it was probably dropped into SysWOW64, and it was as I expected, so I ran this command:
regsvr32 "C:\Windows\SysWOW64\mscomct2.ocx"
and it said it was successfully registered (which means about nothing LOL) but I dropped the files in again - same error.
I have not yet rebooted my machine, and I can if somebody has a compelling reason that's the problem, but generally speaking if the assembly is registered properly with regsvr32 that's not necessary. I've worked with a ton of COM objects and never have to reboot to get to the object as long as I've registered it.
Does anybody know another step I need to perform to get this thing registered?
It is registered as it should. It is your application that is compiled for AnyCPU Platform.
In x64 operating system this produces 64bit code and 64bit code could not access 32bit drivers.
Change your Platform to x86 and you will be fine.
EDIT
Two years later there is something to add to this answer. Now with Visual Studio 2013 the cheese has been moved. The article linked explain in great details how the compiler setup defaults has been changed. The AnyCPU target CPU with Prefer 32 bit means that your application works as 32bit app also in x64bit operating systems leaving practically no-room to x64 application unless specifically required.
With this new configuration becomes also important to remember what is posted in comments below by Mark Berry. If your (now 32bit) app needs to work in a IIS 64bit environment you need to set the Application Pool with Enable 32 bit Applications
I have desktop app (Win7 x64 VS 2015) - and kept getting the same error no matter what. I changed platform target to x86, installed MSI as admin etc - did everything I could google - and no luck. What helped me is to install MSI for Everyone instead of Just me - one of the last wizard's screen in the setup.
I have the same problem.
I install the VFP Ole DB Provider in my system and resolved.
download link
use Advantage OLE DB Provider,works for 32 or 64,here is the connection string
I've designed a WPF C# application using Visual Studio 2012. The application, which is simple enough, runs fine on my Windows 8 machine using the ClickOnce deployment method. The datagrid displays the content from a SQL Server database and performs all of it's other functions just as I've designed it to, but when I attempt to install it on a Windows 7 machine it immediately crashes and I'm not sure why. The Windows 7 computer I'm trying to install the application on has .NET 4.5 running on it, but is there anything else that computer needs to have installed on it in order to run applications developed with VS 2012. This is my first attempt to install an application developed with VS 2012 on a Windows 7 machine, so I'm not sure if there's another step that I'm missing here. Any help you guys can provide would be greatly appreciated. Thank you.
The message you stated "The application has stopped working and that if Microsoft has a solution..." is an indicator of one of the following:
The Framework is disabled; though 4.5 is installed several root instances are built on the foundation which are apart of Framework 2.0. This particular Framework can cause issues for 3.0, 3.5, 4.0, and even 4.5.
The System.EnterpriseServices.dll is damaged in the Framework. Which needs to be connected back to the Global Assembly Cache (GAC).
And another common issue is the machine.config file log in the Framework Folder can be corrupt and needs to be replaced with a valid one.
There are others that can occur within the System Policy Folder as well, which may require you to use the .Net Cleanup Tool and reinstall the Framework. But before you do any troubleshooting you should go to the Event Viewer and get details of what is going on.
Try these steps first for me:
Windows Key + R
When the run prompt appears type: appwiz.cpl
Go to the left hand side: Turn Windows Features On or Off
Turn Framework 3.5 on if it isn't already; if it is already on go to Step 5.
Turn off the Framework; then reboot.
Once rebooted follow steps 1-4 again.
Now at this point I would suggest trying the application again. If it fails try this:
Open Start
Type 'cmd' in Search
Right Click and Run as an Administrator
Type %windir%\Microsoft.Net\Framework\v2.0.50727\ngen.exe update
Then type: sfc /scannow
The Native Regeneration tool will try to repair the Framework back to a factory state; the System-File-Checker will attempt to fix any errors indicated in Windows. If it can't it will say 'it found integrity violations'.
Those are the steps I would do for general support; but you really should try and locate an error message. As the Framework can become a huge ordeal to cleanup and fix. If you provide more information I will revise my response to help address it.
Hopefully that helps.
I have a relatively simple ASP.NET application that I am trying to create an installer for. I am currently using Visual Studio 2008's "Web Setup Project" which, though I'm told is not ideal, has proved no problems when installing on Windows Server 2003 & IIS6.
IIS7 on Server 2008 and Vista has proved substantially more difficult. The installer starts off fine before halting with an unhelpful "The installer was interrupted before could be installed. You need to restart the installer to try again." UAC is switched off, and I've already ensured I'm executing the installer with administritive privledges.
The problem sounds identical to the issue outlined in this blog post, however I have the IIS6 Metabase Compatibility role service installed already. I've also tried playing around with AppPools, the Integrated/Classic pipelines and so on, all to no avail.
I've since turned on MSI logging and, whilst I found nothing concrete, I believe the rollback begins somewhere around this error message.
The error indicates that IIS is in 64 bit mode, while this application is a 32 bit application and thus not compatible.
This doesn't make any sense to me whatsoever, as both Vista and Server 2008 are 32-bit installations. I suspect it's a red herring, but I can't be sure.
Has anyone encountered a similar problem, and if so, is there a solution that doesn't involve me moving to a different installation framework?
Try putting a friendly lil checkmark beside each node in
[Programs and Features // Turn Windows features on or off // Internet Information Services // Web Management Tools // IIS 6 Management Compatibility]
Note that I had the same symptoms posted in the blog though, and this fixed it for me. Yours may be different.
Just tackled this last night, therefore my sincerest good luck to you.
In order to fix that error message for those using Windows 2003 x64, use the following commands from a cmd prompt:
cscript.exe %SystemDrive%\Inetpub\AdminScripts\adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 "true"
cd WINDOWS\Microsoft.NET\Framework\v2.0.50727
aspnet_regiis.exe -i
Source:
How to Run a Microsoft .NET 2.0 or higher Web Application in 32-bit Mode in IIS 6.0 on a 64-bit Server
Note:
By doing the first step, you will now notice that the ASP.net tab is no longer visible.
This is a known bug and the work around is too use scripts to change the .Net version for any running sites.