I have a problem and I don't know how to work around it: I used the WMPLib in my C# application (located in C:\Windows\System32\WMP.dll). I referenced it and dded it in the header of the main form's code file:
using WMPLib;
But if I try to run my app on a Windows N edition (I think also the KN edition counts here), it stops working and Windows shows the following message: "App-name has stopped working. You can check for a solution...". So now, I'm trying to find a way to work around this, for example, by not importing that DLL at run time when user is running a Windows N edition.
I'm afraid that I wouldn't have a way to redistribute my app to Windows N users.
Thanks for any advice,
Vali
The N editions do not come with Windows Media Player installed by default, which explains why the DLL is missing. Windows Media Player can, however, be installed after the fact.
This leaves you with two choices:
Dyamically load the DLL at runtime
Check for, and require that Windows Media Player is installed as a prerequisite (i.e., during setup)
You may actually want to do both. If your application requires this assembly to get its job done, on app startup, you probably want to check if the DLL is available. If it isn't, displaying a meaningful error message would be preferable to an outright crash.
Related
so I'm implementing printing for my UWP app following this guide https://learn.microsoft.com/en-us/windows/uwp/winrt-components/brokered-windows-runtime-components-for-side-loaded-windows-store-apps#creating-and-deploying-the-windows-runtime-proxy
I have a bug where the printer stops working and I realized one fix is to go into task manager and delete the COM Surrogate associated with a dll. I'm not sure how to find out what dll this is, has anyone ran into this issue before?
I would think the fix is to relink the component somehow but am not sure how.
The proper way to print from a UWP is using the Windows.Graphics.Printing, Windows.UI.Xaml.Printing, PrintDocument APIs as documented here:
https://learn.microsoft.com/en-us/windows/uwp/devices-sensors/print-from-your-app
One thing to note is that this approach currently does not support silent/unattended print scenarios. For those you would have to work around using classic Win32 printing API, either from a brokered component (as you tried) or using a desktop extension to your UWP. The latter is the preferred route (brokered components is Win8 era tech). I have a quick tutorial on desktop extensions here: https://stefanwick.com/2018/04/06/uwp-with-desktop-extension-part-1/ and a very simple silent printing sample here: 1drv.ms/u/s!AovTwKUMywTNnOsbzlRfghOikDy8Dw
I have used this technique (Brokered Windows Runtime Components) in an LOB app for several years, and it is always a PITA for the maintenance.
Every time I have made an update to Brokered Windows Runtime Component I will need to register it again using regsvr32.exe. If I have run the app and COM Surrogate is already running, the registration will fail. I will need to reboot the system, or I have to kill the running "dllhost.exe" in task manager - there might be several instances of dllhost.exe, and I just kill the ones that run under the current logon user, and leave those run as SYSTEM.
One of the dllhost.exe instances hosts the DLL you created and registered. It is not clear why printer stops working so I can't give an answer. To help investigation, add some logs to these points.
When the app code is calling the Brokered Windows Runtime Component, check the return value of the call, and try and catch any exception.
Inside the Brokered Windows Runtime Component, at the entry and exit of the method that is being called by the App.
Check the code that uses printer, is it working correctly? or is it being called at all?
I have created an app in C# .Net 2.0 that uses the AxShockwaveFlash object to display youtube videos given from the youtube API. The object itself works fine on the PC I am doing the development (normal Windows XP) but as soon as I put it on our release machines (XP Embedded) the shockwave object just appears as a white screen.
I have added the following:
Registry settings:
[HKEY_LOCAL_MACHINE\SOFTWARE\Macromedia\FlashPlayerPlugin]
"Path"="C:\\WINDOWS\\system32\\Macromed\\Flash"
"Version"="11.1.102.55"
"PlayerPath"="C:\\WINDOWS\\system32\\Macromed\\Flash\\NPSWF32.dll"
[HKEY_LOCAL_MACHINE\SOFTWARE\Macromedia\FlashPlayerPlugin\Components]
"Main"="1"
Adding the flashplayer.xpt file to the location specified and the NPSWF32.dll to the same place as well. This hasn't changed anything but I am stuck and have no real idea what to do. Anything I have missed?
For anyone interested we were missing a few files that the object required in order to run, unfortunately I don't have a list of them to hand at the minute, will have a look for the specific names if requested.
this problem has me baffled.
I'm writing an application which is supposed to take information from a form, pass it to a background worker which then a) writes the information to a local xml file and b) inserts the information into a remote MySQL database.
On my development machine, it seems to work flawlessly. The remote database is updated, the xml file is created if necessary and updated if it already exists. It's working.
Even if I exit out of the development environment and run the release build independantly of the IDE sandbox, the code works.
But, if I put it on another machine, the code fails and I dont understand why.
I'm currently using Visual Studio 2010 Professional on a 32 bit Windows 7 Ultimate machine.
At the moment, I'm finding that the application is stopping at a fairly specific point, which seems to be precisely where the background worker starts doing things like accessing the file system or accessing the remote database.
The project consists of a single exe file and a dll, which has a custom control I designed in it. The custom control is working fine, in that it shows what I want it to and returns the values I'm asking it to when I want it to, so it would seem that isn't to blame.
I initially thought I could be looking at a permissions problem, but running the application as administrator gets me the same response.
I've been writing using version 4 of the .NET framework, however I've just downgraded that to version 3.5 in the hopes that that may help. Both the non-development machines I've tried have been up to date - or have been brought up to date by me - prior to attempting to run the application.
I'm honestly baffled here. Any suggestions would be most welcome.
Alan
If your code fails, it most likely means there is some uncaught exception. What you should do is to log all uncaught exceptions (and probably some of the caught too) to a file, possibly using something like log4net.
I don't think we can help you beyond that.
I have written a live logging utility called Donsole for diagnosing the application in such conditions. On the developer workstation, it is very easy to diagnose using the feature-rich debugger of VS. The utility app. helps the developers exactly in this kind of scenarios where they don't have any idea what's happening inside. I recommend you download the latest build and try it for yourself. Explaining how to use this utility and how it works is beyond the scope of this answer, so I'd forward you to the codeplex page of the project.
http://donsole.codeplex.com/
This is how it looks.
Take a look at the event viewer of your operating system. Administrative Tools>Event Viewer>Windows Log>Application.
I just like to code when i travel,but i can't carry my laptop while travelling so i thought of a mobile in which i can create apps in C#, .NET or Java but for that i need an IDE,Compiler,etc.
Basically I am looking for a phone / mobile / PDA (far more handy than a net-book or a laptop) in which i can code the way i can do it normally in Visual Studio installed in a machine.
So are there any such devices ?
Let's take a look at what you need to overcome to get this to work.
1) oomph
Smart phones are designed to give you the ability to stay in touch, and have a rich experience on the move, but within the confines of a device that can be put in your pocket. Storage isn't really an issue these days, but processing power on small devices are. Sure we can run calendar, 3D games (though nowhere near the complexity of what you'll see on a fully-fledged operating system), fart-applications and plug-ins for you-tube so we can watch idiots break their ballsacks on railings, but there's a reason you don't see a fully-fledged rich-desktop application, or Grand Theft Auto IV on these devices. Oomph. Now bring in the Visual Studio development environment (and database server, if that is what you're application is doing), with potentially 100s of source files in your language of choice. Assuming we put a severly cut-down version of your IDE on to your pda, I hope you brought some spare batteries or the power-cord because you're going to need it.
2) input
It's probably not difficult to change your predictive text input to cover all the keywords of your chosen language so that you don't end up typing pubic instead of public. Once we've solved that we then need to go through the agonizing process of the fact that computer code contains a lot of symbols and identifiers, meaning we'd have to switch our input mode every other word or two to facilitate it:
for(int i(0); i < _vector.length(); i++)
Takes a few seconds on a keyboard. Probably about one train journey on your PDA. To solve this, we must assume the PDA has the facility for an external keyboard to prevent suicide.
3) display
Ok, we've solved our oomph problems with a power-chord and/or 50 batteries and we've plugged in our external keyboard. We're ready to code!! We'll have to adjust the font-size on the display so that we can get more than 20 lines of code (vertically) or 10 (horizontally). I enjoy my comfort when I code, so I don't want to be squinting at a small screen as I type on my plug-in keyboard. I'd have to prop it up against some books or something (so I don't have to hold the PDA and the keyboard). Now I can't see what i am doing. So, I need a bigger display.
4) Target code
What platform are you targeting? Remember the PDA is designed to run software for the PDA in question. You won't be able to write fully-fledged win32 applications on Windows Mobile 7. There are differences in the API. What if it's a web app you're developing? We're going to have to add a web server to the phone too, unless that is deployed elsewhere and we can rely on an internet connection to upload the changed files to.
Have we solved the problem? Did we get more oomph? A keyboard? A bigger display? Yes we did.
It's a laptop.
It's impractical, as Moo-Juice mentioned. However, you could try using online compilers that work through web browsers, such as Compilr.com. Perhaps this could work well enough through a mobile device's web browser. This way you could write snippets of code and verify that it compiles. Otherwise, you'll be stuck getting a netbook or laptop.
Use a VNC client or Remote Desktop client or something.
Obviously your experience will not be very good on a phone/PDA, but I also don't have an IDE installed on my laptop -- I just use remote desktop (and a wireless modem if I'm desperately bored and can't find wifi).
I have made a toolbar that I want to enable from a systray application written in C#, the actual toolbar enabling is done from a C++ part using [DLLImport].
Current I use:
SHLoadInProc(__uuidof(MyBandLoader))
but this fails on vista (SHLoadInProc is not implemented any more), and on Windows XP SP2 with IE6 (the quick launch toolbar vanishes after reboot).
On Vista I have tried to with: CocreateInstance() and BandSite->AddBand(), but using the guid of the toolbar dll gave me either a segmentation fault or the address bar.
Is there another way to enable a toolbar from another program on XP and Vista?
On Vista there's a new poorly-documented interface called ITrayDeskBand.
Create an instance of this via CoCreateInstance, and then call ShowDeskBand([CLSID of your toolbar]) on the returned pointer (in C++ - I'm not sure how you create all the relevant bits for PInvoke in C# - might be easier to write a simple C++ dll to expose this function)
That only works on Vista though, on XP you need to continue with the SHLoadInProc method above, so you need to test the OS version and do the appropriate thing.
Be careful if you're lifting code from that codeproject article - it's full of subtle bugs, although many of them are discussed in the comments
I have used that one, but it only tells you have to make a toolbar, not how to enable it from another program.
One should never use .Net to create any COM objects inside the Explorer process. This will just not work if there is another .net component using a different framework version already loaded into the explorers process. Only one .net framework for each process. MS should have never propaged samples about developing deskbands in any .net language.
The only way on Vista an up is to use the ITrayDeskBand interface to display the toolbar. However, this will display a confirmation box to the user and he can refuse the toolbar to be shown.