I've got a Visual Studio installer project (a vdproj) that won't install the VC redistributables as a pre-requisite. I can't figure out why.
I'm using the latest updates to Visual Studio 2019, with the Installer Projects extension. Here are my prerequisite settings:
At install time I get an error that says vc_redist.x64.exe has changed since it was initially published. I checked bootstrap at C:\Program Files (x86)\Microsoft SDKs\ClickOnce Bootstrapper\Packages\vcredist_x64 and discovered that the URL found there (https://aka.ms/vs/16/release/14.26.55555/vc_redist.x64.exe) redirects to the main microsoft home page and downloads HTML rather than an executable. So I changed the URL, first to https://aka.ms/vs/16/release/vc_redist.x64.exe, then to https://aka.ms/vs/16/release/14.27.29016/vc_redist.x64.exe. Both of these URLs download a copy of VC_redist.x64.exe when you visit them with a web browser, but neither of them fixes the installer.
The only difference I see after changing the URL is that with the original URL I get a file named vcredist_x64\vc_redist.x64.exe in the temp install folder (but it's invalid, full of HTML), but with the two new URLs the vcredist_x64 folder is empty.
Any idea what I need to do to get this working?
I found the solution. I needed change the URL and the public key. Here are the steps you would follow to resolve an issue like this in the future:
Find the URL to a version that is still available. The latest version is currently available from here: https://aka.ms/vs/16/release/vc_redist.x64.exe. The version-specific URL to that same file is currently http://aka.ms/vs/16/release/14.27.29016/vc_redist.x64.exe.
Note the version number. If you don't already know it, you can get it by simply hovering over the downloaded file in file explorer.
Find the public key. I learned how to do that from an answer in this question. You find the key by right-clicking on vc_redist.x64.exe, selecting properties, Digital Signatures, then double-click on the sha1 entry. Click View Certificate, then Details, then Public key. Copy the value that shows up in the text box.
Remove all the spaces from the public key you copied. The public key for v14.27.29016 of vc_redist.x64.exe is:
3082010a02820101009208daf213e09ec32da6e2dfdaef8c19ec2f584f0bf53f20b806f33f91258f36cf27d114def85bd87d4f84f6e7f4b7b9d8940cc78cafa99627f60610fe36076121443cb15c163b7f6d8ef4111e33f6fffbd2bc87e69a446830bd488678ecf64422650cd8443618469f71490626470423939865f3f53b4603a24038ad547694ec14f5308f7695f651b882030d805dbd7b5b7256093153b0a99b6fd0ef73402adeb7a47e7d148668335f104a5c20b2fe0fb455dcce2e6891384dae8a00e76f57e315689a7561715364f2ada631cee9df691d03d9886ecd742e906e74469ac6b8f2e350adbe807e62ca0c8d4ba77d56328813697e6d65ff82653f4f4aebe33822cd0203010001
Open C:\Program Files (x86)\Microsoft SDKs\ClickOnce Bootstrapper\Packages\vcredist_x64\product.xml in a text editor, as administrator.
Replace the value of the PublicKey with the key you prepared in step 4.
In the BypassIf element, replace the Value with the version you noted in step 2. Save and close the file.
Open C:\Program Files (x86)\Microsoft SDKs\ClickOnce Bootstrapper\Packages\vcredist_x64\en\package.xml in a text editor, as admin.
Replace VCRedistExe with the URL from step 1. You can use either the generic or the version-specific URL. They both have drawbacks. Save and close the file.
Rebuild your installer.
You may need to make adjustments for your environment.
Regarding the choice of URL, I suspect neither will work forever. If you use a version-specific URL, that version might go away (which is the whole reason we're needing to mess with this in the first place). If you use the version-agnostic URL, then when a new version comes out the product key probably won't match.
It's really unfortunate that Microsoft makes existing installers break by taking old redist packages down, and doesn't provide the updates required for new installers to work out of the box.
Related
Hi DocuSign CLM geeks and the DocuSign API in-house team-
Our team will be using DocuSign CLM with the DocuSign Edit add-on to easily open Microsoft Word files and save back to CLM.
We'd like to include the installation of DocuSign Edit in our Silent Mode installation configuration. We're hoping there's an msi File available for the DocuSign Edit extension? If so, please link!
Plan B- If we were to make our own msi from the available exe, does anyone have a trail stomped out for doing this? (a blog post, documentation, step by step, video demo, even a horror story)
Thanks for tips.
https://tools.springcm.com/sites/default/files/apps/docusign-edit-pc-2.01.00.exe
This is an exe that is built from an MSI, so it is an MSI.
If you want to get the MSI out of this https://www.codetwo.com/kb/msi-from-exe/:
The first method is based on the fact that most installers extract their .msi files to the temporary files folder during the installation process. To extract an MSI file from an EXE installer, you need to:
Launch your .exe file.
When you see the first prompt (e.g. a question about whether you want to continue installation, accept a license agreement, etc.), do not click anything in this window and do not close it.
Open Windows Explorer, type %temp% in the address bar and press Enter.
Sort the files in the folder by the modification date. The newest file on the list should be the .msi file you are looking for.
Copy the MSI file to a safe location before you close the installer prompt window (see step 2). Be aware that if you close the installer window, the MSI file will be immediately deleted from the temporary files folder.
The second method uses a free third-party tool called 7-Zip to browse the content of the .exe installer file. Follow the steps below.
Download 7-Zip from this page and install it.
Right-click on the .exe file (from which you want to extract an .msi file) and from the shortcut menu choose 7-Zip > Open Archive.
Do not extract any files yet. Instead, browse and look for the folder MSI within the contents. It might take some time to find this folder because it is not always located directly in the root directory (its location may vary depending on the installer).
When you locate the MSI folder, you will notice that it most likely does not contain any .msi files, but a file or files with no extensions and rather cryptic names such as 132. Despite these misleading names, these are actually the MSI files you are looking for.
Drag and drop these files to any desired folder or select them and extract them with 7-Zip. Close 7-Zip after that.
Change the names of the extracted files so that they include the .msi extension.
If there are two files, the larger one is the 64-bit installer, and the smaller one is the 32-bit version. Use the one you need.
Finally, if you want to tweak an MSI, you can use the Orca tool by Microsoft - https://learn.microsoft.com/en-us/windows/win32/msi/orca-exe
I want to clone a github repo that uses two different files/folders:
\packages\ - Folder
\Packages - File
However, due to windows not using Case Sensitive File/Directory Names, this isnt working, it gives me the error that the folder cant be renamed because a file already has the same name.
The program that uses this project REQUIRES that there be a no-extension binary text file Packages (Its like a giant file full of control files (If you recognize linux debian youll understand)
But it also requires a folder named \packages\ to hold the json files containing the config data for each control file within Packages
This question is an updated form of this previous question, which is outdated, and doesnt have an answer that solves the problem: Working in git with directories with the same name but different case in Windows
From Windows 10's update in April of 2018, they added a feature to "enable" case-sensitivity on specific directories.
I simply used the command on my github storage directory and now my project works fine.
To use the feature: Open a command prompt window (I dont believe this requires Administrator, it didnt for me)
Copy the full directory path to the folder you want to enable the flag on, type in the console:
fsutil.exe file SetCaseSensitiveInfo #:\Path\To\Directory\Here enable
Paste your C:/D:/E: or whatever Drive path into the location above. Then hit enter.
You DO NOT need to restart your computer, the flag seems to take effect immediately
Info sourced from: https://www.windowscentral.com/how-enable-ntfs-treat-folders-case-sensitive-windows-10#enable_case_sensitivity_ntfs_windows10
I've got a pretty simple installscript MSI project - it copies some files into a folder, updates a few registry keys and that's pretty much it.
When I try to use the Repair function (either by re-launching the installer, or by choosing the app's Modify option under Apps & Features), I get the following message, when it gets to the "Copying new files" stage:
"The feature you are trying to use is on a network resource that is unavailable.
Click OK to try again, or enter an alternate path to a folder containing the installation package 'project.msi' in the box below."
The path in which it looks for the .msi file is %TEMP%\[SOME_RANDOM_HEXADECIMAL_STRING]
This random hexadecimal string doesn't seem to be specifically related to the project. It's neither the Product Code nor the Upgrade Code nor the Package Code.
When I look for it in the registry, I find it in the values of the following keys:
Computer\HKEY_CLASSES_ROOT\Installer\Products\[SCRAMBLED_PRODUCT_CODE]\SourceList\LastUsedSource
Computer\HKEY_CLASSES_ROOT\Installer\Products\[SCRAMBLED_PRODUCT_CODE]\SourceList\Net\3
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\[ANOTHER_SCRAMBLED_PRODUCT_CODE]\SourceList\LastUsedSource
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\[ANOTHER_SCRAMBLED_PRODUCT_CODE]\SourceList\Net\3
Looking at the %TEMP% folder, I can find the .msi file in a folder that has another random hexadecimal string as its name. That folder does not appear in the registry at all.
I don't want my clients to go looking for .msi files every time they want to repair an installation of my product. How can I let the installer know the .msi file's location?
The source files you installed from are probably just missing since your temp folder has been cleaned out (where the install originally ran from).
There used to be a cache the whole MSI - feature you could enable on a release-configuration basis (Cache MSI Locally). This would "solve" this problem I believe by caching the whole MSI in a safe location (see section 3). Many do this, despite the increased disk space used.
Another option is to install from an administrative installation (essentially an extract of your setup's files - run via setup.exe /a or msiexec.exe /a MySetup.msi - which has been put available on a network share, always available for repair or modify operations). This is what corporate deployment uses to support repair and modify operations.
We recently installed NuPeek for our NuGet repository and NuPeek as symbols server.
NuGet works (above) fine. It was set up within an hour.
The Symbols Server on the other hand is a different story. Packages are pushed to NuPeek (normal packages and symbol packages). I see on the server that both are picked up and placed in the correct folder (source files too, .cs in this case).
I have set up Visual Studio so it can find the correct symbols server. When I create a new project, install the package (that also has a symbols package), use the code from that package and try to debug it, the following happens:
In the cache folder the "package" is downloaded
The cache folder also has a src folder. Within a source folder which has a folder with the same name as the package -> version.
The version folder is empty
The folder cache/ packagename.pdb/guid/ packagename.pdb is present
Still, Visual Studio cannot find the correct CS file to show. After some digging in the NuPeek server folders I noticed the folder symbolsPath -> temp -> PackageName -> lib -> net45 is empty, while the symbols.nupkg clearly has sources (one cs-file to be excact).
I had this working before, but we switched servers (Azure website to Azure CloudService), but I'm 99% sure this is not the problem.
Am I missing something? Does anyone has any clue?
Thanks in advance!
Does anyone has any clue?
If anyone does then the author of the project, Jérémie Chassaing, would be the most likely candidate. Don't hesitate to add an issue to the issue tracker. Not much there right now and he looks pretty responsive so worth your time.
Do run through the setup checklist first:
Tools + Options, Debugging, Symbols, add http://myserver/NuPeek/symbols to the Symbol file locations list. Ensure that you have a valid Cache symbols directory selected
Tools + Options, Debugging, General, tick the "Enable source server support" option
Untick the "Enable Just My Code" option.
Tick the "Print source server diagnostics" option. Update your question with what you see in the Output window so we'll have a better shot at figuring out the real problem
Ok, this is an old question but as i found the solution today i'll post it here.
This is probably because you instaled NuPeek too deep in your website structure.
A bug in Nupeek requires that it is installed at the root level of your site (for ex: www.domain.com, and not www.domain.com/Nupeek/).
Else you can fix the bug in SymbolTools.cs, replace the SourceBaseUri getter code by this :
private static string SourceBaseUri
{
get
{
var httpRequest = HttpContext.Current.Request;
var applicationUri = new Uri(new Uri(httpRequest.Url.GetLeftPart(UriPartial.Scheme | UriPartial.Authority)), Path.Combine(httpRequest.ApplicationPath, "source"));
return applicationUri.ToString();
}
}
Hope this helps.
I have Visual Studio 2012 and when I'm trying to get last version it doesn't work and it says that it's says that "All files are up to date". It is because I deleted file locally after I got it from TFS and I guess in Visual Studios memory it's written that there were no changes from that time I got it and now it doesn't let me download it although I don't have it.
How to "tell" VS that my local folder is changed?
P.S. I guess it can be also done with "Get specific version" but that option doesn't appear to me when i right-click on file I want to get from server.
EDIT:
I found that my workspace changed automatically (or rather with me not being concentrated while making new project), so VS was actually checking other directory all the time. For all those who might have the same problem - check your local path and if you see that it's not good, change it.
Here is how you can change it:
http://social.msdn.microsoft.com/Forums/en-US/tfsversioncontrol/thread/d0c6982f-4f5e-4b1c-830b-3af9fb127922/
You are right, TFS saves what version he gaves you and changing/deleting it without to notify TFS, you won't get anything. The "Get Specific Version ..." is what you need. Therefore rightclick on the item you want, in context menu choose "Advanced --> Get Specific Version". Check the second option to "Overwrite all files even if the local version matches the specified version".
Not saying this is a solution, but I had similar issues after remapping one of my projects. Ultimately what I did was delete my local Solution File (.sln) and re-opened the project via the Project File (.vbproj). After that I was able to see all of my latest file versions that appeared to not be down loading. Once you click save on anything it will re-prompt you to save a new solution file.
i don't know if this is specifically what the OP was trying to accomplish, but here's my story: my machine crashed, had to get it reimaged; once VS2015 was installed, i went to source control explorer, right clicked the branch i needed >> Advanced >> Get Specific Version, checked the "Overwrite..." boxes, clicked "Get" and got the "All files up to date..." message. buster. obviously the code was NOT up to date.
fast forward: i fixed this issue by deleting my workspace's pertinent mapping to code base i needed, saved it, and re-added it.
hope this saves some headaches.
You'll want to Get Specific Version and to check the box to enable overwriting of existing files. That will ensure you're actually up to date.
You can also switch from a server worspace to the new local workspace which should also help solve issues like this.