This question already has answers here:
What could cause Vb6 run time error 430
(3 answers)
Closed 5 years ago.
I created one application (*.exe) it works fine in all systems but in one system it throws an error.
"class does not support automation or does support expected interface "
Using a simple Google search:
Either the class you specified in the GetObject or CreateObject function call has not exposed a programmability interface, or you changed a project from .dll to .exe, or vice versa.
To correct this error Check the documentation of the application that created the object for limitations on the use of automation with this class of object.
If you changed a project from .dll to .exe or vice versa, you must manually unregister the old .dll or .exe.
It will Occurs when launching an installation of FRx that resides in a different directory than the one that was specified when FRx was installed on the current workstation. For example, launching an FRx install that resides on the server, instead of the one that was installed locally. Register the FRXLICSYS.DLL and FRXSYSTEM.DLL files in the directory from which FRx is being launched. If the problem persists, uninstall and reinstall FRx Version 6.0
Note If you are running Microsoft FRx version 6.7, register the FRXLICSYS67.DLL file, instead of the FRXLICSYS.DLL file.
follow below steps to resolve your concern:
Manually register the required files.
Using Explorer, locate FRXLICSYS.DLLin the directory from which FRx is being run.
Note If you are running Microsoft FRx version 6.7, locate the FRXLICSYS67.DLL file, instead of the FRXLICSYS.DLL file.
Choose Open With from the menu.
Click the Other button at the bottom of the Open With window.
Browse to the local drive (most often C:), and select either REGSVR32.EXE in \WINNT\SYSTEM32 or REGSVR.EXE in \WINDOWS\SYSTEM.
Click Open.
Click OK. A message will display indicating whether the file was successfully registered.
Repeat steps 1 through6 for FRXSYSTEM.DLL.
Related
I have tried to create an .exe file to my WPF App and SQL Server related databse with EF Core using Windows Setup Installer Project.
I included all the dll's files from /bin/Release and built it for any CPU.
The Setup Project has been created successfully and it worked on my PC as I expected.
Otherwise when I try to install the Setup File on another PC, I can't even open it up and see what's wrong.
I guess the problem comes from the database but I can't find anything helpful on the internet.
So you get the application installed, run it and nothing happens, right? Here is what you do:
Run it. Watch nothing happen
Hit the Windows key and type "Event"
When "Event Viewer" appears in the list of applications, run it
In Event Viewer, go to Windows Logs >> Application
Near the top there will probably be an error entry. It will probably be related to your application. And if you were missing a key file needed to run your application, like a DLL, the name of the file will probably be in there in the details section
Go back to your installer and add that missing file. Or if that file is part of some support package (like, say, MS Redistributable for Visual C++) then add the installer for that too.
I need a single exe-file on a windows pc executing a .Net WPF program. This file must be signed with a code authentication certificat. With this certificat the exe-file is executed on foreign windows system without system warnings or administration rights after copy deployment by user to a trusted place.
I can do this with VS2019 and .Net 4.7.2. But I want go forward to VS2022 and .Net 6.0. Below a simple sample working with VS2019. You can step over signtool, because in VS 2022 already fails the posibility to create a single exe files. Same happens with VS 2019 and .Net 5.0 already in the past, but I find some post with information that single exe-file with WPF first work in future with .Net 6.0. Now, after release of .Net 6.0 and VS2022 I try it again. More options in deployment assistent for single file are available, but nothing creates a single exe-file!
Working process in VS2019:
I create WPF-App (.Net Framework) WPF4Test using .Net Framework 4.7.2
I put code sign command ("C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\signtool.exe" sign /a /n "my company name" /t http://timestamp.comodoca.com/authenticode $(TargetPath)) in postbuild step
I build release and enter password of certificate during sign process
bin\Release folder contains 3 files (WPF4Test.exe, WPF4Test.exe.config, WPF4Test.pdb)
I copy WPF4Test.exe to share folder and application is executable and signed
I test process in VS2022 with .Net 6
I create WPF-Application WPF6Test using .Net 6.0
I deploy Application in a folder (in assistant i must select folder twice) (default set configuration Release and destination runtime portable)
pubxml is created and i publish application
deployment folder contains 5 files (WPF6Test.deps.json, WPF6Test.dll, WPF6Test.exe, WPF6Test.pdb, WPF6Test.runtimeconfig.json)
I copy WPF6Test.exe to share folder, but application not start without error message
If I copy the whole folder to share and application run.
I can delete WPF6Test.deps.json and WPF6Test.pdb, but i need 3 files (WPF6Test.dll, WPF6Test.exe, WPF6Test.runtimeconfig.json).
I go back to VS2022 and add additional pubxml file with changed profil option (deploment mode independent, create single file, activate compile ready to run).
But now I get 7 files (D3DCompiler_47_cor3.dll, PenImc_cor3.dll, PresentationNative_cor3.dll, vcruntime140_cor3.dll, WPF6Test.exe, WPF6Test.pdb, wpfgfx_cor3.dll).
What do I have to do to get a single exe file?
How I can sign this exe file during publishing process?
You need to set 'IncludeAllContentForSelfExtract' in the project file or if you using the CLI to build 'IncludeNativeLibrariesForSelfExtract'.
Even if you tick or set single exe if you are producing a self contained exe it will not including the native libraries.
Project File (your-project.csproj)
<IncludeAllContentForSelfExtract>true</IncludeAllContentForSelfExtract>
.Net CLI
dotnet publish -r win-x64 /p:PublishSingleFile=true /p:IncludeNativeLibrariesForSelfExtract=true --self-contained true
Edit your publish profile settings,
Select Deployment mode as Framework-dependent
Select the target runtime to something other than Portable (Produce single file is not available for Portable)
Under File Publish options, select Produce single file
Save the profile settings and try publishing again.
This should produce a single exe file.
If you select the Deployment mode as Self-Contained or independent, it will produce 7 files as you mentioned.
Hope this helps for publishing to a single file!
I have a simple Windows Form application(WPF) with entity framework. After compiled, only a few files generated:
EntityFramework.dll
EntityFramework.xml
MyApp.exe
MyApp.application
MyApp.exe.config
...
Then I just copy following files to a network shared folder:
EntityFramework.dll
MyApp.exe
MyApp.exe.config
Then I can double click on MyApp.exe from developer computer the launch the app, but can not launch from another end user computer.
How to resolve this problem?
When you double click, app is not launching means certainly it is crashing so type the command eventvwr in run or cmd it'll open the Event viewer in that go to Windows Logs and Click on Application, you can see different levels of logs in that just find the last error log view the details it might help you
Have a look in the event log on the target computer and look at the error that is actually being reported.
It could be a missing installation of the correct version of the DotNet framework as suggested in the comments above, or it could also be that the execution policy of the target computer is preventing the user from running from a network drive (As a developer you probably have admin rights on your local pc allowing you to do this).
Whatever the actual cause you are always better to use some form of installer, rather than this form of putting files on the network (commonly known as xcopy deployment).
Probably the best solution is to use Visual studio to generate you a click once installer and publish it to your network drive. This will then copy the application locally on the users pc and run it from there.
Let's say that I have created a form or a console application. This form application's only dependency is .NET Framework (not a 3rd library) and application doesn't have any kind of requirements. What it does is to take a file and transforms to something else.
Does this application need to be installed? Can I just copy .exe file that is under \bin folder and share it?
First, you need to make sure that Copy Local is set to true for all the references of your start up project. Setting copy local to true will make sure that the DLLs get copied to the output directory. Then, build the solution and copy all the files from your output directory to any machine where you want to run the application. The application should work, as long as it has the appropriate .NET framework installed.
Here's a link about how to set copy local to true: http://msdn.microsoft.com/en-us/library/t1zz5y8c%28v=vs.100%29.aspx
There are 2 Ways to Do This... I just did this 20 Min Ago :)
Method 1 : Right Click on Your Project, Publish, Choose Location For
The installer. This installer can be copied onto other machines, installed and run
Method 2 : Your bin/release folder will contain .exe files which need to be copied and Installed, i prefer the 1st method. It avoids missing important / Needed Files for execution
Just a Side Note. Make Sure the Output Type Is of Console Type (Right Click on project... Output type...), Some windows applications give Problems when Publishing and Installing them due to the frameworks that might be missing
We have a silverlight(5) project, the source in TFS (2010) and Continuous Integration build has been setup and working fine. However, we are now at the stage where we are trying to release it to some users to get them using it and give feedback. I've set up the code so that it checks for updates and if there are any it downloads the latest xap file. However this requires the xap file to be signed. No problem when doing this from our dev machines, but when it comes to the automated build it fails, with the message
Xap packaging failed. Cannot locate the signing tool SignTool.exe.
I've tried numerous things to get the signtool to be recoginised and can't. However, we don't actually need this on the CI build, so I've then tried a second tack which is to make the postbuild event conditional on being run in VisualStudio. Followed various suggestions here on SO but can't gett them to work.
The post build event is
if "$(BuildingInsideVisualStudio)" == "true" (
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\signtool.exe" sign /f "$(SolutionDir)castle.pfx" "$(TargetDir)Castle.xap"
copy "$(TargetDir)Castle.xap" "$(SolutionDir)Castle.Web\ClientBin"
)
still no joy. Have tried multiple variations of this, but keep getting the same message from the automated build.
So can anyone help with either a) getting the signing tool to be recoginised on the build server or b) getting the automated build to skip the postbuild event?
Found the problem in the end...
I had been putting in place some features so the app would download and install the latest xap file. This requires it to be signed. As this wasn't working I followed some instructions on signing a xap file, not realising that one of the other developers here had put in place the code I described above in the post build event.
I had mistakenly thought that this was created as a result of me checking the 'Sign The Xap File' check box.
So first issue was that other developer had not shared his pfx file with us to add to our certificate stores.
Second, and main issue, was that we then had two attempts at signing going on. The one via the check box and the one via the post build event. I removed the check box and it worked fine.
The issue with the check box is that it expects the SignTool.exe to be in a particular location. On our development boxes with full VS it is where it is looking for it, but on the build server it wasn't. Think it may also have something to do with 64bit machines.
By using only the build event (once you have the correct certificates installed) you can specify explicitly the location that the signtool is going to be, and if necessary install the windows sdk to that location.
This is the top result in Google for this error so updating it with my steps to resolve.
The above didnt work for me but performing the steps below should fix it.
Install the Windows 8.1 SDK on the build server (Windows 2008 R2 for me)
Adding the Windows SDK BIN directory (that contains signtool.exe, on my server) to the Environment PATH variable - e.g. c:\program files (x86)\Windows Kits\8.1\bin - note: Do not add quotes around this
Restart all the Visual Studio Team Foundation services in services.msc after you add the file path to the PATH variable as it needs to reload these before building