I developed the project in visual studio 2010. That exe file is not supported for other PC's.
which dotnetframework to be installed? other than dotnetframework is there any other requirements needed?
Are you sure it's not the CPU type you specified during compiling (x86 vs x64 CPU). If you compiled in 64-bit and a user only has a 32-bit processor (x86), your code won't run.
The .Net Framework should work on any PC-based system, but be sure to include it in your deployment or setup package. (you can provide Excel, .NET Framework, and many other packages with your package.)
You should also try to find out what error messages your users are receiving -- which will point you in the right direction.
Related
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 ran Dependency Walker on an assembly (.exe) after compiling in Debug (Any CPU) and it seems like there are older core and kernel issues. The entire code is VB.NET 2010, so I am wondering why VS2017 Pro didn't clean those out?
Something interesting was that the Conversion to a new VS version did not occur, for which errors are shown -- it just showed the forms, modules, etc. as if there were no errors.
Should I try a Reload or something?
The errors were caused by having old references or assembly libraries which called DLLs (like VBIDE.dll and MSCORE.DLL) in the applications folder. There were very old references, some of which were to VB6.
Recall, remember that Visual Studio has always been dropping certain Windows forms controls over VB 2005, VB 2008, VB2010, etc. so you need to make sure those older controls are not in forms when you upgrade to e.g. VS 2017.
I am a .NET developer with limited experience in C, C++, and C++/CLI.
We have an old program which is still being developed in Visual C++ 6.0, strictly in C (no C++ features). I've been asked to develop a C++/CLI DLL for this application which allows the application to run some routines that were written in .NET. I'm using Visual Studio 2013.
The machine being used to develop the C application is running Windows XP, has .NET 4.0 installed. We have gotten it to link with the C++/CLI DLL and everything compiles fine. However when we run the software, nothing happens. The user interface doesn't show up and there are no error messages. The process just shows up in the Task Manager for an instant, then goes away. Kind of hard to debug when we don't have any error messages. If we comment out the DLL function call, the software works as usual.
We're using good DLL practices such as extern "C" {...}, __declspec(dllimport), __declspec(dllexport), deploying msvcr120.dll along with my DLL, etc. We set up a dummy test DLL without C++/CLI support to make sure we are creating DLLs correctly and everything worked fine.
Does this mean it's impossible to use a C++/CLI DLL in an old C program?
EDIT: I got it working on my development PC (Windows 8.1), but not the Windows XP development PC with VC6. On the Windows XP PC the program crashes before it even calls the DLL function.
It turns out this is an operating system issue.
After I noticed that it works just fine on my Windows 8.1 PC, I took a look at my platform toolset settings for the C++/CLI DLL. To get to those, right-click on the project -> Properties -> Configuration Properties -> General. I was targeting "Visual Studio 2013 (v120)" when I should have been targeting "Visual Studio 2013 - Windows XP (v120_xp)". After I changed that setting, the DLL started working on the Windows XP machine.
I have the dreaded issue from my attempted installation of an MSI:
MSI (c) (98:B0) [18:01:22:818]: Invoking remote custom action. DLL: C:\DOCUME~1\sspencer\LOCALS~1\Temp\1\MSI19.tmp, Entrypoint: CheckFX
MSI (c) (98:FC) [18:01:22:833]: Cloaking enabled.
MSI (c) (98:FC) [18:01:22:833]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (98:FC) [18:01:22:833]: Connected to service for CA interface.
Action ended 18:01:22: DIRCA_CheckFX. Return value 3.
After quite a bit of digging, this is actually indicating that the DLL failed to load outright, the CA server was unable to connect and start hitting the DLL entry points.
I used orca and 7zip to extract the custom action for the DIRCA_CheckFX which is inserted by Visual studio when the deployment project builds. I grabbed the DLL and then executed Dependency Walker in the host system (Server 2003 R2) which gave the error:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
I recompiled the system using the VS 2010 compiler, extracted the DLL and ran dependency walker on it, which did not create the same error. I.e VS 2010 compilation works, VS 2013 compilation fails as the included DLL won't load in the target environment.
My question is how do I troubleshoot which DLL(s) are missing in order to troubleshoot that error reported by Dependency Walker.
Must be installed VS 2010 from which you can get the valid file "dpca.dll".
Close Visual Studio 2013
Copy file with replace dpca.dll from
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\Deployment to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\VSI\bin.
Open Project
Rebuild
The preview of the .vdproj resurrection uses DLLs that don't support Windows XP or Server 2003. Microsoft posted an update that might have fixed that bug.
Here's what I did to workaround this issue for a 32-bit deployment project.
Build the setup project in VS2010 once. This package is not dogged by the issue but I didn't want to have to keep building in a different VS version.
Open the resulting msi with Orca, select the Binary table and export the content of MSVBDPCADLL to a file.
Now after you build it in VS2013 use Orca to import the exported data into Binary\MSVBDPCADLL to fix the package.
I have to do a similar thing with the 64-bit project but in this case it's to import the correct InstallUtil binary (being C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtilLib.dll).
Visual Studio deployment projects were so horrible that Microsoft removed them from Visual Studio 2012. Developers were so ignorant as to why they were horrible that they begged and begged for them to come back. The smart guys at Microsoft who understand MSI left the building and the people remaining caved to the developers asking for it to come back.
One of those really smart guys summed it up perfectly in a tweet:
The return of vdproj: Headshots, people, or they come back as walkers.
I wrote an article on my feelings: Visual Studio Installer Resurrection
So let's talk about the way the tool is failing you this time. Take a moment to read this article written by one of the other really smart ones to leave MSFT:
Zataoca: Custom actions are (generally) an admission of failure.
VDRPOJ created a custom action to do something MSI could have done natively and now it's failing. So let's say you find the DLL and fix it to work on your machine. What happens when you ship your MSI to 1,000,000 machines? How many machines will it fail out there? How many support calls will you get? How many tweets will you get that your product sucks?
Simply put, I'd redo your installer using a better tool such as Windows Installer XML and Industrial Strength Windows Installer XML. If you have the money to spend InstallShield Professional is a good choice also.
Using VS 2010 Ultimate on my Windows 7 64-bit machine, I wrote a Windows Forms Application with Visual Basic and then compiled it with "Build" command specifically for x86 platforms ( I have tried assigning both "x86" and "Any CPU" on Active solution platform options in Configuration Manager). I have also made sure that TargetPlatform is set to x86 on Project Properties.
However, when I'm trying to run the .exe or the .msi file on my XP 32-bit machine, I get this message:
"This product is designed for x64 platform but is being installed on Intel. Obtain the correct setup from the manufacturer."
.NET Framework 4 client profile, which is a Prerequisite for my application, is also installed on the XP machine.
Does anyone have a clue for this? How can I fix this?
Thank you for your time.
I'm not sure about 2010, but in VS2008 it is sometimes necessary to go to Project Properties, Compile, Advanced Compile Options, and change the target CPU to from AnyCPU to x86.