I have a C#.NET Windows Forms project which compiles, builds and runs without any problems on Windows. Now I'm trying to migrate it to OSX using Mono. The project compiles and builds, but I get an exception (see attached image). When I double-click one of the entries in the stack trace, it says that the file couldn't be found. Does this mean that I forgot to install something when I installed Mono (i.e. something related to support for Windows.Forms) ????
Any help is appreciated - thank you!!
I don't think NotifyIcon is supported on OS X: Bugzilla
Related
I have tried to create an installer with visual studio installer project on windows 10 version 1909 (x64). The application setup is created and works fine in installing the application also I do not face any issue running the application on system.
But if i try to install the application on other system with windows 10 version 1909(x64), it installs the application sucessfully on that system as well. But when I run the application it gets abruptly closed without giving any errors.
I have tried looking for the windows logs then I see an error with the error code 0xc0000409. I have tried the possible solutions for this error available on the internet like clean boot or running system file checker but nothing seems to work on that system.
What could be possibly going wrong , please help..
I've got a problem with an wpf application.
I programming a wpf application with sharpdevelop 4.1.8000, it complied successful and is running well on the development machine.
When I copy the files from bin\debug to other machines (include the third part dll I used in project), the tool can't startup. I got a exception, the exception component is System.Windows.Markup.XamlParse. I don't know why this happened.
So I need your help. By the way, the development machine is win7 x64 enterprise, the version of .net framework is 4.0. The deployment machine were win7 x64, too.
Check your xaml namespaces, did you reference something that is in the GAC of your develop machine but bot present on the other client. Happened to me using a behaviour from System.Windows.Interactivity, worked on my dev machine because i had Blend installed but which wasn´t the case on the client.
Error. The type or namespace name 'GridViewExpressionColumn' could not be found (are you missing a using directive or an assembly reference?)
Hello all,
I've inherited a VisualStudio 2010, Silverlight 4 project with a custom RadControl from Telerik. The project runs fine on the server, but I would like to make some changes locally. When I copied the project folder over to my c drive, the application cannot compile (build errors). After cleaning the solution, I still keep running into CLS-compliant issues, and most notably, the error listed above. I'm not sure what the problem is, since I've never worked with Telerik or third party RadControls. Any help would be appriciated.
Thank you.
You will need to contact your office software guru and get a licensed copy of Telerik RadControls to install on your local development machine.
To get you compiling, for now, you can use the demo version available at http://www.telerik.com/support/demos/developer-tools-demos.aspx - any solutions compiled from this will show a big "DEMO" banner accross the control for a few seconds.
Our company has a handful of Mac users. I recently built a Winform application and now my main user is using a Mac. Is it possible to run this application on a Mac? What would have to be done to convert it? If it is too much, I may just rebuild it is asp.net as a web application.
Thanks in advance!
JCC
Maybe. Many .Net programs can be compiled with mono as well, winforms usually is not a problem, but some libraries (e. g. MS Office libraries for editing Excel files). I am not sure about VB, as mono coders mostly use C#, but you can analyse your code with the Mono Migration Analyzer for portability to mono.
Depending a bit on features and controls used, it may run on Mono. Since you can run Mono on Windows as well it's rather easy to download and test it.
Your basic options are (from least intrusive to most intrusive, from the point of view of a Mac user):
Convert it to a web app.
Run it on a Terminal Server and have them use Remote Desktop.
Run the application in a virtual machine (VMWare or Parallels) that is running Windows.
Try to get it running under Mono.
If there isn’t a strong reason for it to be a desktop application, you really should be thinking in terms of web apps for new applications—at least, that’s an unwritten rule where I work.
I recently built a new application using WPF, so that I can learn the new technology. Now that I am trying to deploy the application, it appears as if it is running fine on a Vista system, but on a Windows XP SP2 machine with the .Net fx 3.5SP1, it's not able to load the PresentationFramework.dll file.
I did some further investigation into this and discovered that there is a slight build difference between the PresentationFramework.dll files on my xp test machines vs. what is on my Vista development machine.
What I'm curious about is if anyone else has run into this issue as well, and what they did to remedy the situation so that they could develop on Windows Vista, but deploy the developed application to both Vista and XP clients.
Thanks.
I need to add to this a bit... on the vista machine and on the client machine, I've got .Net Fx 3.5 SP1. I had done a bit of digging, and found out that the PresentationFramework.dll file is the same, except the last set of versioning numbers.
Has anyone found a decent work around for this issue?
Sorry that I left this stagnant, but I figured out the issue I was running into. Turned out that there was corruption in the Windows XP box I was using as a test bed.
I was working between stackoverflow and another forum for the package I was writing the Add-in for. When I learned of the answer, this is what I posted, in case I ran into issue in the future.
I thought that I'd post this here, so
that I would have reference, and also
in case anyone else would need
reference to it for the future... I'm
working on another Dinerware Add-on
using WPF, and although it was running
fine on my development machine, every
time I'd go to run it on a test
machine (a machine ghosted like it was
in the field at a customer's
location), I kept getting weird
processing errors.
I did hours of searching online, only
to come up empty handed until I ran
across this article:
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/6e5de3d8-fc02-4504-b00f-7a2192d24a48/
which gives a link to the download of
the WIC (Windows Imaging Components),
located here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=8e011506-6307-445b-b950-215def45ddd8&displaylang=en
For some reason, what is/was happening
is that the Windows Imaging components
have become corrupt against what my
application is looking for. TO fix
the issue, you have to:
1) navigate to
%windir%\$NtUninstallWIC$\spuninst\
and run the spuninst.exe file in
there. That will remove the Windows
imaging components. 2) after you have
completely removed the components, you
will then re-install them using the
second link from above.
So far, I've not run into any further
issues.
What a crazy thing that
was?!?!?!?!?!?!!
Hopefully, if someone else runs into this issue, I may be able to help them out quick by >putting this out there.
As I said on that forum... hopefully this helps someone else out that runs into this issue in the future.
I've done a bit more experimentation and built a test WPF project and used a Setup and Deployment project instead of a WiX installer. for some reason, the application is working fine when its installed with the Setup and Deployment installer, but when using WiX, it's having issues...
Beginning to think the issue has to do with WiX, and not the .Net Fx version/build
You can have this problem sometimes with templates and Blend, although I thought it had been fixed in the latest Blend. Basically when Blend "pulls in" information for making a new template, it can sometimes copy in Aero only stuff from Vista, which means the control you then create is then reliant on Vista :-(
I did think this was fixed though, although you may have been bitten by it if the project has taken a while to put together.
Make sure that .NET Version on your Vista and XP machine are same.