have been working and wearing out my fingers doing google searches with this one:
I generally develop on server side, but we require small desktop apps to connect certain hardware pieces with our web based software -- I put something together with very limited knowledge of VB.Net no issues there. I don't know much about making installers, messing with the registry or signing programs to make antivirus software not flag my executables as unsafe.
My main woe is that I have a DLL file I used for my installation which I don't know how to register during the installation process. I am using VB.Net Express 2010 for the actual application code and InnoIDE to compile an installation script with those files.
Is there a script I can add to InnoIDE so it will register the DLL file for me? Or is this something I can do programmatically from VB.Net (Express version, not full...). The DLL is a COM library, so according to the research I did it requires registering.
As an aside, any information anyone could provide in terms of signing the application or something which will stop antivirus software from warning users that this file could be potentially unsafe? We use Avast in the office and in all test machines Avast tried to have the app run in the sandbox every time I ran it.
Thank you in advance, and please let me know if this question requires further information.
Since InnoIDE is just a graphical interface to Inno Setup you could try using the Pascal Scripting function RegisterServer.
From above link
Registers the DLL/OCX with the specified filename. If Is64Bit is True,
the DLL/OCX will be loaded as a 64-bit image and registered in a
64-bit process. If FailCriticalErrors is True, the system will not
display any critical-error-handler message boxes. Raises an exception
if not successful.
Related
I am working on a project to make an Autocad addon for our engineering department. The project is nearly finished, but when I build the project and send the dll to my colleagues for them to add in autocad, it is not working for them. I can not seem to find a solution on the internet.
- I am using Visual studio 2019
- Autocad 2020
- I make the dll's by releasing it on a x64 platform
- They "netload" it in autocad and the commands that work on my device do not work on theirs
I hope somebody can help me, I am a self thought vb.net engineer for autocad, so I am not that experienced with the basics.
The signing thing should not be required - it works okay here.
Some things to check:
in VS2019, did you set Copy -> false for the DLLs that are referenced ?
when the receiver of your DLL does a right-click on the DLL (in the file explorer), is there an option to unlock the file ? If so, unlock it
Use AnyCPU
I always distribute the Debug version, maybe give that a try ?
is there an error message that you can share ?
It's trusted on your device but unless it's signed it won't be trusted on other machines. That is a security requirement to stop unsigned assemblies from running unknown script.
You can use a self signing certificate for your own machine but unless it comes from an known certification authority it may kick up a stink. You could attempt to add it to their Global Assemby Caches or to see some security is blocking it.
I created a program in vb.net in vb language. After that I created an installer (.msi) for the same in Advanced Installer program. I installed it on the computer and everything seems professional.
I copied the folder that contains the program and all its dependees and sent to to a different computer. I was surprised that the application (.exe) file works without installation!!
How can I make my application works only with installation?
Appreciate the help.
Advanced Installer has a licensing module that works for VB.NET apps too, which you can easily integrate into your installer.
However, this is in the Enterprise edition, and I assume you are using the free edition, as this sounds like quite a simple application/installer.
In this case you can try looking for an alternative OSS solution for a licensing/trial library.
Basically with this library every user that needs to use the software will need a key to activate it, so even if they copy the folder with the application files from Programs Folder, they will still not be able to run your app.
I developped a vb6 program then I build an installation wizard with visual studio interdev.
I used "dependency walker" and "process explorer" to find out the missing DLLs but there is always a problem with :
IESHIMS.DLL
WER.DLL
MPR.DLL
These dlls shown by dependency walker.
And when installing the program on another machine I have these error messages :
uxtheme.dll failed to register
msdatsrc.tlb failed to register etc..
PS : no problem on a machine where visual studio is installed.
Any Idea to fix this issue?
Thanks
Dependency Walker is not an appropriate tool to troubleshoot VB6 dependencies. It works well enough for DLLs written in C or C++ that use implicit dependencies. Although it hasn't kept up with the times and has trouble with DLLs that are stored in the Windows side-by-side cache or are delay loaded. Delay loading is what generates the warnings on ieshims.dll et al.
VB6 uses COM, which loads DLLs dynamically with LoadLibrary(). You'll never see such a dependency back in Depends unless you use the Profile option. Such DLLs are found back through the registry, the reason you needed to write an installer and tinker with regsvr32.exe.
You have to be pretty careful when writing installers like that, VB6 is old and can depend on operating system components that have been updated many times since 1998. Like uxtheme.dll, an important operating system DLL that implements visual styles. Having your installer overwrite the existing one on the user's machine is, well, disastrous. Although it is probably protected by Windows through its File System Protection feature, something that got added as a counter-measure against broken installers.
Giving proper advice is here difficult beyond "do no harm". A commercial installer like InstallShield or Wise (which I liked back then) is the best way to avoid shooting off the customer's leg. Fairly sure they still support VB6 installs. Microsoft makes a pre-cooked installer available for VB6 that installs all the core vb6 runtime components. You can download it here.
You should ALWAYS double check and verify any dependancies that you think your application needs.
All the files you mentioned are system DLLs and MUST NOT be distributed.
For a VB6 application you need the basic runtimes, and any DLLs you explicitly reference/use if and only if you have permission from the authors of those DLLs and instructions on the correct procedure and location for installing them.
For the standard Microsoft provided OCX files, these normally just need to be copied to the system32 folder and registered.
See redist.txt in the root of your Visual Studio installation for more details.
does vb.net have a different way to build an application without using clickonce?
If your application doesn't need an installer then you don't need to use ClickOnce at all. Just do a build in Visual Studio to produce your exe and off you go. There are actually quite a few single-file applications on the internet that are done this way.
If you do need a proper installer, I still wouldn't normally suggest ClickOnce. ClickOnce was designed to allow a user to literally click a button in a web browser just "once" to install your product into a secure-but-limited sandbox. The sandbox where the application lives will then have limited permissions to the file system and such. It's pretty cool in theory. But in practice the limitations involved can become a pain for any but the most basic of applications.
For a powerful installer system for Windows, I'd suggest NSIS. It's free, open source, and scriptable. I've used it to build the installer for a couple of VB.NET software applications. One of them has been downloaded & installed by thousands of users. I'm also the main point of contact for technical support and I haven't heard a single report of a problem with the installer itself.
I could go on and on, but suffice it to say that I've tried others such as InstallShield and Wise and even ClickOnce (that was short-lived). But nothing could compare to the speed, power, reliability, and lightweight-edness of NSIS.
Command line:
vbc /out:MyProg.exe MyFile.vb
Generally when I use ClickOnce when I build a VB.NET program but it has a few downsides. I've never really used anything else, so I'm not sure
what my options are.
Downsides to ClickOnce:
Consists of multiple files - Seems easier to distribute one file than manageing a bunch of file and the downloader to download those files.
You have to build it again for CD installations (for when the end user dosn't have internet)
Program does not end up in Program Files - It ends up hidden away in some application catch folder, making it much harder to shortcut to.
Pros to ClickOnce:
It works. Magically. And it's built
into VisualStudio 2008 express.
Makes it easy to upgrade the
application.
Does Windows Installer do these things as well? I know it dosen't have any of the ClickOnce cons, but It would be nice to know if it also has the ClickOnce pros.
Update:
I ended up using Wix 2 (Wix 3 was available but at the time I did the project, no one had a competent tutorial). It was nice because it supported the three things I (eventually) needed. An optional start-up-with-windows shortcut, a start-up-when-the-installer-is-done option, and three paragraphs of text that my boss thinks will keep uses from clicking the wrong option.
Have you seen WiX yet?
http://wix.sourceforge.net/
It builds windows installers using an XML file and has additional libraries to use if you want to fancify your installers and the like. I'll admit the learning curve for me was medium-high in getting things started, but afterwards I was able to build a second installer without any hassles.
It will handle updates and other items if you so desire, and you can apply folder permissions and the like to the installers. It also gives you greater control on where exactly you want to install files and is compatible with all the standardized Windows folder conventions, so you can specify "PROGRAM_DATA" or something to that effect and the installer knows to put it in C:\Documents and Settings\All Users\Application Data or C:\ProgramData depending on if you're running XP or Vista.
The rumor is that Office 2007 and Visual Studio 2008 used WiX to create their installer, but I haven't been able to verify that anywhere. I do believe is is developed by some Microsoft folks on the inside.
I agree with Joseph, my experience with ClickOnce is its great for the vast majority of projects especially in a corporate environment where it makes build, publish and deployment easy. Implementing the "forced upgrade" to ensure users have the latest version when running is so much easier in ClickOnce, and a main reason for my usage of it.
Issues with ClickOnce: In a corporate environment it has issues with proxy servers and the workarounds are less than ideal. I've had to deploy a few apps in those cases from UNC paths...but you can't do that all the time. Its "sandbox" is great, until you want to find the executable or create a desktop shortcut.
Have not deployed out of 2008 yet so not sure if those issues still exist.
Creating an installer project, with a dependency on your EXE (which in turn depends on whatever it needs) is a fairly straightforward process - but you'll need at least VS Standard Edition for that.
Inside the installer project, you can create custom tasks and dialog steps that allow you to do anything you code up.
What's missing is the auto-upgrade and version-checking magic you get with ClickOnce. You can still build it in, it's just not automatic.
I don't believe there is any easy way to make a Windows Installer project have the ease or upgradability of ClickOnce. I use ClickOnce for all the internal .NET apps I develop (with the exception of Console Apps). I find that in an enterprise environment, the ease of deployment outweighs the lack of flexibility.
ClickOnce can be problematic if you have 3rd party components that need to be installed along with your product. You can skirt this to some extent by creating installers for the components however with ClickOnce deployment you have to create the logic to update said component installers.
I've in a previous life used Wise For Windows Installer to create installation packages. While creating upgrades with it were not automatic like ClickOnce is, they were more precise and less headache filled when it came to other components that needed to be registered/added.