I'm currently using a 64-bit Based Windows 7 OS. I build the program in a x86 platform. Still Emgu.CV.CvInvoke appears. oh and I'm using .Net 3.5 framework... One thing all file properties are already in(Copy always)...
Related
Built a UMCA 6.0 APP on Laptop 1 with platform target set to x64 and framework target set to .Net Framework 4.8. Laptop 1 is X64 based CPU running Windows 10 Enterprise. Application runs as designed.
Copied the executable and DLLs to Laptop 2, where UCMA runtime and .NetFramework 4.8 were installed. The process also required installing Visual C++ 2015-2019 redistribution. Got the infamous SIPEPS error message.
Copied the project directory (source code, project file, etc.) to Laptop 2 and rebuilt the app after doing a clean. Confirmed project properties included X64 and .Net Framework 4.8. Build was successful 1st time. Ran the app and still getting the SIPEPS error message.
Both laptops are Dells with i7 cores. Using VS 2017 for build. Need to have a backup machine for this app. If the primary fails - we are dead in the water.
You must uninstall all Visual C++ releases greater than 2013 before UCMA 6.0 will properly install. I also did a repair of .Net Framework 4.8. Installed UCMA 6.0 before anything else and that seems to have addressed this particular issue.
Now its on to a new issue: "Recorder cannot start due to I/O Error."
Im developing continually an inventor Addin in VB.Net in visual studio 2019 ,
i have multiple machine different builds , but once in a while some machine just don't want to load the Addin f.e. the current version i have now works on all machines except one AMD machine .
When i compile the same project with the same settings no changes at all on the AMD machine with ANY CPU build option it runs without problem . When i do it on my primary developing machine it does not work on this other computer.
I checked dependencies with dependency walker , i do not get any error messages .
When i make breakpoints in DEBUG mode and debug dll compilation in the first methods called in the "StandardAddInServer.vb" file it does not reach it on the AMD machine when it is compiled on the Intel machine. But in reverse it runs smoothly .
I have no idea what this could be and I'm only speculating that is has to do with AMD/Intel difference of the machines . Any help would be appreciated to come to a solution.
Inventor 2018.3.7 Professional Build 287 is on the Intel i7-4771 machine Visual Studio Community 2019 16.3.9 , .NET 4.8.03761
Inventor 2018 Professional build 112 is on the AMD Ryzen 7 3700X machine Visual Studio Community 2019 16.7.2 .NET 4.8.03752
Any more information which could be helpful will be provided gladly .
Well.... i tought lets make the maschines identical in regards to software .. i started installing inventor updates one by one at Version 2018.3.1 the Addin magically was working .... so i hope i help somebody if the , addin automatically unloads without any error , its probably autodesk inventors fault ...
Are you using ANY CPU ,or are you forcing the project to a given bit size?
If you don't set this, and leave it at ANY CPU? Well, if you launch the application from Visual Studio (such as installing on that target machine), then the application will run as x32 bits.
HOWEVER if you launch the program from the windows command line (command prompt).
Well, if you use the x64 bit command prompt, you get a x64 bit running - in-process program. If any of your external .dll's or libraryes are x32 (or not compiled with ANY cpu), or you using any un-manage code libraies (say like ghostscript or some such)? Then your program will run (or try to) as x64 bits.
However, if you launch a x32 bit windows command prompt (there are two of them - one is x32, and one is x64). So, if you launch the .net exe (your program) from a windows x32 bit prompt, then your program will run in-process as x32 bits.
So, be careful here. Using ANY CPU from Visual Studio will ALWAYS get you a x32 bit program - including debugging. But RUNNING the program (launching outside of VS) will not always be x32 bits.
And the above behaviours seems to explain your issues/problems on the AMD machine. It was NOT that you installed VS on that machine, but that using VS to launch your program in fact FORCED it to run as x32 bits.
Bottom line:
do NOT use ANY CPU unless that is exactly what you need, and that you are VERY sure any external libraries are also compiled as ANY CPU, or in fact that any external libraries doe NOT USE any un-managed code.
All in all? I would config your project to force run as x86 ALWAYS, and thus you not get some surprises of code not working.
I doubt very much that the AMD CPU is the issue, and installing VS only worked because of forcing your project to run as x32 as opposed to x64 bits. It has zero to do with AMD here.
You could try with a former framework version like 4.6.2. That should fix the problem. It could be that the newer service packs of Inventor can deal with addins created with newer .net versions. When 2018 Inventor was released, .net 4.8 was not available.
Was Albert wrote is true as well. If the architecture of your dll doesn't meet that of your host process, it can't be loaded. A 64bit process can use 64bit dlls only whereas a 32bit one can deal with 32bit dll only. A .Net project won't be compiled by Studio into fully functional machine code (nowadays you can do this as well), but intermediate code only, which will be compiled finally by the .net framework on the target machine. If anyCPU is selected, you don't have to provide different versions for different hardware because of this behaviour.
I'm developing an application for a friend. I use Visual Basic 2012 (64-bit) and Windows 7 (64-bit).
I took a demo down to him to try it out to see what more features he wanted, and it was running ok.
When I got back the next week after implementing the new features, it refused to run on any of his Windows XP (32-bit) machines.
Error code:
MyApplicationName.exe is not a valid Win32 application
I tried it at a computer running Windows 7 (32-bit) which still worked all fine.
So, any ideas why it suddenly stopped running?
VS2012 will not generate an EXE that can run on XP when you use the default project settings. What matters is the .NET Framework version you target. If that's version 4.5 then there are two problems.
First one is that .NET 4.5 is not available for XP. Second one is important for this exception message, the compiler will mark the version of Windows that's required to run the EXE in the file header. That version number has always been set to 4.00. Until VS2012, it is now set to 6.00, the version number of Vista. XP will instantly reject your EXE with the "is not a valid Win32 application" message, even before it will tell you that it doesn't have .NET 4.5 installed.
Fix your problem by targeting .NET 4.0 or earlier. Project + Properties, Application tab, Target framework setting.
Try using corflags with /32bit+ and see if it works.
More information:
http://msdn.microsoft.com/en-us/library/ms164699.aspx
We have built an app with Visual Studio 2012 and it runs beautifully on any Windows 7 or Vista machine, 32 or 64 bit. However, when I try to run the app on an Win XP machine, I get this:
**
Prerequisite check for system component Microsoft .NET Framework 4.5
(x86 and x64) failed with the following error message:
"Installation of the Microsoft .NET Framework 4.5 is not supported on
this operating system. Contact your application vendor."
**
And then of course, when I try to install .NET 4.5 on the Win XP machine, I find out it's not supported.
At this point, I'm just wanting to know what can be done to get this app to run on Win XP. It's a calculator application written in visual basic.
Thanks Guys!
.Net framework 4.5 is not supported in Windows XP. If you're not using any .Net 4.5 features you can rebuild your app using .Net Framework 4 (In the Project properties).
I always hate these kind of answers, but a quick google search indicates that you can't get .net 4.5 to run on Windows XP.
IF you really really need your application to run, you can always use earlier versions of the framework
you can do this by
Right click on your project and go to
properties
application
target framework
and change that to something elxe
I found that links:
Microsoft .NET Framework 4 (Web Installer)
Microsoft .NET Framework 4 (Standalone Installer)
Microsoft .NET Framework 4 Client Profile (Standalone Installer)
Note that (2) the size is 48.0 MB and the (3) the size is 41.0 MB. It's not the REAL .Net 4 Full Standalone. :(
I want that installer in a usb pen drive because my app need of features of .Net 4 Full Framework (like MSBuild) and I will install in a enviroment without Internet access.
PS: I tested the (2) and really is the Client Profile with another name... :(
Actually, you already found the full .NET 4 SDK. Microsoft put in a lot of effort to decrease the size.
The Microsoft .NET Framework 4
redistributable package installs the
.NET Framework runtime and associated
files that are required to run and
develop applications to target the
.NET Framework 4.
Have a look at this hanselpost.
The prerequisites have changed since .NET 3.5 SP1, .NET 4.0 requires at least XP SP3, Windows 2003 SP2 or Vista SP1. .NET 3.5 could be installed on any version of these operating systems, including a 11 year old completely unpatched version of XP.
So the 3.5 installer also needs to be able to update a bunch of native Windows components.
Not having to include the Windows component updates and additions allowed for a significant size reduction. If that's an issue then you'll have to include the Windows service pack installers on your pen drive.