I am trying to distribute a program in our small business environment. I tried to choose therefore ClickOnce in Visual Studio 2019 and DotNet 5. However, if I open the EXE from the published folder, it tells me that a DLL is missing. After adding this one, it tells me another DLL is missing, aso. In contrast, if I publish to a local folder, everything works as expected.
What may I do wrong? It seems like the missing DLLs have something to do with PowerShell automatization (Microsoft.Management.Infrastructure) which as I understood is only available as either x64 or x86. I tried to restrict my program to x64, however, without any success.
If you know any other simple distribution method for a small business (all pcs conneted locally) I am very happy and thankfully.
The solution was simple. Missing dependencies can be added here, during the setup for ClickOnce export creation.
Related
I've been trying to make an installer for an exe file, yet I can't seem to get it work. Whenever the setup.exe is run, it errors with the message
Setup has detected that C:\Users[name]\AppData\Local\Temp\VSD4F7F.tmp\vcredist_x64\vc_redist.x64.exe has been changed since it was initially published
I attempted to make it download from the same location as my PC, but that too didn't work as when it was building the solution it errored saying that the files were not found. I put the right files in the Packages folder, yet it still didn't work.
For reference, I'm using a 64 bit PC to develop, the exe was designed for 64 bit, and the clean PC that I'm testing on is 64 bit. I'm also using Windows 10 and Visual Studio 2019.
I have the same issue, and I found sort of a workaround:
It seems that when installer creates bootstrapper (the setup.exe) it embeds information from C:\Program Files (x86)\Microsoft SDKs\ClickOnce Bootstrapper\Packages\vcredist_x64\product.xml. More precisely, it seems to embed the public key of the vc++ redistributable in the setup.
When user runs the setup, bootstrapper downloads the vcredist from Microsoft's web (in my case https://aka.ms/vs/16/release/vc_redist.x64.exe) and checks the digital signature. If the public key of the downloaded file doesn't match the embedded one in setup, you get the error.
Now, I managed to fix it (sort of) by manually editing C:\Program Files (x86)\Microsoft SDKs\ClickOnce Bootstrapper\Packages\vcredist_x64\product.xml putting the downloaded vcredist public key into the xml file and rebuilding the installer project.
However, if Microsoft again changes the signature on vcredist, my setup will start throwing errors again.
It is driving me insane. I'm considering:
a) removing the prerequisite from my installer and instructing users to install vcredist
themselves
or
b) Hosting vcredist on my own website (and checking "Download prerequisites from the same location as my application)
Both of these solutions have significant drawbacks and yet, updating setup each time Microsoft releases "new" vcredist is not an option either
I've made multiple C# DLLs in MS Visual Studio which I then access from Excel via VBA calls. These work fine on my machine (obviously VS COM registers them for me when compiling as long as I have the right boxes ticked). I also got them working on other machines by searching my registry for any seemingly relevant keys to each of the DLLs, and copying the entries into other machines registries. Obviously that's madness though, so I want I want to make a simple installer so I can install said COM DLLs on other machines easily.
Since I have a windows forms app in there to test all the DLLs, I figured it makes most sense to just make an installer for that app, and the other DLLs should get installed as they're dependencies. Right-clicking, and publishing gives me the setup.exe. I can then install this on the other machines. But the DLLs aren't COM registered on the new machine, so although the test app works, I can't actually use them from Excel/VBA.
What do I need to do? (googling only seems to turn up pretty old stuff that I can't seem to follow with older versions of VS)
I'm using the full version of VS 2019.
I'm using the basic right-click/properties/publish to make a setup.exe and associated folders.
I may get more options by adding an MSIX installer project into the solution? But I've never done that before so when I tried the learning curve of that it seemed a nightmare and wouldn't compile, largely complaining I didn't seem to have an icon of every size under the sun included. Trying to use VS to auto-generate them from 1 image caused VS to crash every time. I can try sitting in paint making them all manually if that's my only option, but it may be pointless if I don't need and MSIX installer anyway.
At this point I'm also interested in just COM registering them manually for sanity sake without typing in the registry entries, and can work on the installer later. But as far as I can tell regasm/gacutil aren't on any of these other machines. (I also haven't used that before, so am somewhat confused by which I should use, and if I need to do it for both x86 and 64.)
I'm a noob to VS installers, DLLs and the registry (and associated terms), so please try keep it simple. Although obviously I've got as far as making C# DLLs I can call from VBA (once COM registered), and they otherwise work a treat.
Intro
I don't know if this is a bug or there is something I'm completely missing.
I have a Project (Windows Service), let's called it WINSERV. And I have 3 DLL's which it depends which come from 3 seperate Projects (Project A, B, C). However A has a dependency on C. And B has a dependency on A and C.
When Building Installer with InstallShield LE, for some reason my Project C is always a STALE version which I cannot get to change. I increment the version, "make clean && rebuild", and the installation (on a remote server) always includes the STALE version.
I set each project that has a dependency on C, to not "Copy to Local", so allowing Project WinServ to maintain the "reference" itself, and copy it across for the Installer.
Problem
But again, no matter what I do, when I install it's the stale version. After a few hours, I did manage to get around the problem, by removing "Copy to Local" on Project WINSERV, and adding in Project C as an addition to Application Data (Project C's Primary Output) to the InstallShield Install Project. This seems to work!!!!
Question
I did try "MAKE CLEAN" a thousand times. I checked Project C DLL version before building and creating the Installer and it was always STALE, old version.
Anyone can explain this? or Bug?
PS. InstallShield LE does not do Windows Services so if you reading this, don't get caught out.
It's definitely a bug in Visual Studio 2012.
I've managed to replicate in the following fashion:
While having a Project opened (referencing let's say MYSQL 5.1.4).
I then commence to uninstall the MySQL Connector and install 5.1.7.
I close Visual Studio 2012 and recompile and all works well.
However when I build with InstallShield it still references 5.1.4 despite it being uninstalled. My thoughts is that it's caching it somewhere and accessing it later during the build process.
How I solved it, is after installing a newer/older/different version of an existing DLL, I then REBOOT my machine and all is now well.
Hope this helps someone
Sounds like a similar problem I had.
For some reason InstallShield sometimes gets DLLs from the temporary ASP.NET folder (even if your project is not ASP)
Try clearing the folder: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
I have the following error on the build server for code that compiles and passes tests fine locally.
(150): The imported project
"C:\Program
Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets"
was not found. Confirm that the path
in the declaration is
correct, and that the file exists on
disk.
I've added the WebApplications folder from my local machine to the appropriate path on the build server but I'm still getting the same error on build.
I believe the recommended approach with TFS2008 was to install VS2008 in it's entirety on the build server. Is this still the case with TFS2010 and VS2010 accordingly? a.k.a Sledgehammer to crack a nut.
Pretty much, especially if you plan on using other features like MSTest. You can try just adding the targets file but you'll probably still have some missing dependencies. You could go through the whole process of fixing the dependencies as you go along but it's probably easier just to install VS 2010 and be done with it.
This blog post seems to describe a way to do what you want without having to install additional software on the build server, if all you need is the .net compilers. It does not cover C++ compiler setup.
I discovered that if you're going to do just "standard" (i realize that's open to interpretation) web apps and non-web apps (e.g. services), you can get away with installing just Visual Studio 2010 Shell, plus Visual Studio 2010 SP1 on the build server. That will get you the missing .targets files.
Since a full VS install is required for advanced features, does anyone know if the build-server-install license cost is waived?
A lot of people new to CI (Continuous Integration) install VS (Visual Studio) on their CI server "because it is required to compile the code". MSTest is a common reference brought up here.
Why should I not install VS (or generally speaking, any software not out-of-the-box) on my CI server?
(This question has not been asked before apparently, so I'm adding it for reference. If it already exists, sorry, I missed it, please merge. If no answer is provided to this question within some time I can add one myself)
Because you don't need to. A Visual Studio license is pretty expensive, so having one just lying around on a server where no one's using it is just a waste.There are a couple of arguments why you would still need to install a full blown Visual Studio instance on your Continuous Integration server - but here are their counter arguments:
Reason 1: I need it to compile.
Reality: No, you don't. You need MSBuild to compile, but that is available for free, in the Windows SDK. Note that there are several versions for different operative systems and .NET versions, so be careful to download the correct one.
Reason 2: I need it to make quick fixes on the server.
Reality: No, you don't. You shouldn't make quick fixes on the server - you should check out from your version control system, make the fix, build and run tests locally until it works, check in, and have the CI system do the rest for you. That's why you have a CI system.
Reason 3: Without Visual Studio, I can't run MSTest no my CI server.
Reality: Wrong. AFAIK, the MSTest runner is also part of the SDK (at least that's what it seems like on our CI server here - although I can't verify it since we don't have any tests at the moment...). However, a quick googling found this blog post which explains how to do it without the SDK as well. I haven't read through it in detail, so I can't promise that it works, or that it's legal. You have been warned.
Feel free to add more reasons in comments, and I'll counter them.
You might need to install Visual Studio anyway, out of practicality
I was going to try and refute the accepted answer, posted by #TomasLycken, in the comments, but found I needed more space to talk. Even though I technically agree with what #TomasLycken has asserted, here, I'll list some of the dependencies that I found difficult to install on my CI server - and leave it to you to decide how right the accepted answer is...
1 - 'mshtml' primary interop assembly
You can see the problem I was getting in my build output at this S.O. question I created and answered. Mind you, I spent several hours figuring out how get the desired PIA registered - and it was a result of running some .exe's on the server that came from my V.Studio installation - hmmmmmm
CONTEXT: I had a win forms project that used the Web Browser control.. and in the 'WebDocumentCompleted' event, I was casting the DomDocument to hshtml.IHTMLDocument2 .. and that's why I had a reference to Microsoft.mshtml in my project.
RESULT: Now #TomasLycken suggests I deal with this by fixing my code. At first, I wanted to bawk at this suggestion. My code is deployed and working! But, when I do a web search, I see that Microsoft doesn't really recommend using their mshtml PIA outside of the Visual Studio environment they developed it for.
The offending 10 lines of code was effectively doing a little screen-scraping of data on behalf of our users who do research on technical topics in several well-known web portals. But, when I tested this code, written in 2009, it appears that the DOM it once manipulated has now changed in 2016. I know shocking. Probably not my smartest bit of code. Probably time to retire this function - in other words, fix the code and recommit it.
#TomasLyken I think is right on this one.
2 - Win Forms Project post-build script
CONTEXT: So I had come across this cool post-build technique on S.O. that allows my app.config file in my WinForms project to undergo an XDT transform similar to the way my web projects' web.config files are transformed. Well, it just works OOTB, so-to-speak, if you copy from S.O. and into the .csproj or .vbproj source file. But, once you put all this onto a build server with no Visual Studio, the critical piece fails due to a dependency on:
$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
Now this is straightfoward enough to rectify.. I just copied over to the CI server my C:\Program Files (x86)\MSBuild\Microsoft directory. But, should I? Since I've kinda went off the reservation of what Visual Studio normally would support.. one could argue that #TomasLycken's accepted answer is still right on this point, too.
3 - Just getting all the .NET Frameworks and Multi-Targeting Packs in place
Points 1 and 2 above, were actually the last things I conquered in my attempt to get my first build job to run. And my first build job is for a solution stack that I've created and maintained over the past 8 years.. so it has weathered a few frameworks and would have some non-trivial texture to it. I knew it wouldn't be easy. In fact, I hoped by making a CI server that could build this .sln, that it would in fact be ready to build most any other solution we threw at it.
When I first received my clean "Windows 2012 R2" server, it simply had a lot of things missing.. and I'm wondering if I had installed Visual Studio first, if it would have rectified some of these things straight off?
Below is my synopsis of what I had to do - but it doesn't show the pain and suffering involved figuring it all out and the false starts. Maybe it'll help someone else, though.
> First, uninstalled 4.6.1 framework
-- (find Update for Microsoft Windows (KB3102467) and click Uninstall.)
-- also uninstalled anything from MS labeled with C++ redistributable (a later step will restore these)
> Then, install Windows 7 SDK (installs critical "reference assemblies" and a proper baseline 4.0 framework)
-- Then, install Multi-Targeting Pack for Framework 4.0.1 (netfx_401mtpack.exe)
-- Then, install Multi-Targeting Pack for Framework 4.0.3 (netfx_403mtpack.exe)
> Then, reinstalled 4.6.1 framework for 2012 R2 (KB3102467)
> Then, installed Microsoft .NET Framework 4.6.1 Developer Pack (DP461-DevPack-KB3105179-ENU.exe)
> Then, installed "Visual Studio 2015 Build Tools" (BuildTools_Full.exe)
> Downloaded a copy of nuget.exe and put it in the C:\Windows directory
4 - Getting rid of 'missing ruleset' warning MSB3884
From #kevinbosman's post on this GitHub issues thread
If you don't want to edit your Microsoft.CodeAnalysis.Targets file, please note that it is not enough to merely copy the folder C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\Rule Sets\ to the build server.
You also need to create the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\Setup\EDev and add the string value StanDir = C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\
5 - Getting MSTest to run correctly
Need dlls copied into your build machine, some must register w/GAC more info here specifically:
Microsoft.VisualStudio.QualityTools.Resource.dll
Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
Need a hive out of your dev machine's registry copied into build server
some warnings, if you want them to go away, according to this Microsoft visual studio help forum require a VS 2010 and feature pack 2 installation.