Due to a problem with my storage, I need to delete or change location of many folder in my User space, but I see a .nuget folder and I would like to know if there is a way in Visual Studio 2016 to change the location of this folder?
It includes all the packages downloaded for my projects and it takes a lot of space.
Set the globalPackagesFolder propety in your nuget.config and you can point this to any location on your drive. For an overview of the NuGet.config file check out our documentation here.
E.g
<configuration>
<config>
<add key="globalPackagesFolder" value="..\..\GlobalPackages2" />
</config>
</configuration>
This is NuGet cache and can be cleared easily.
In Visual Studio hover over NuGet Package Manger under Tools Menu and click on Package Manager Settings.
Now click on Clear All NuGet Cache(s).
This "Clear All Nuget Cache(s)" will clear all the packages from the default.
You can change the path using NUGET_PACKAGES environment variable
Related
I want to change the version of cxf on Service Mix 7.0.1 where cxf version is 3.1.9 . Because of using Brave tracing that is implemented in 3.1.12 version of cxf.
So Is there a way to change the version of the CXF on Service Mix.
I have deleted manually everything in the system/apache/cxf folder that has 3.1.9 version and add a file with 3.2.5 version. But it is still not working. When I write feature:list all of the cxf dependencies are with 3.1.9 version...
Deleting files from the system folder won't work. It does not scan the system folder for files, but rather uses it as a cache to go looking for specific versions. You don't need to add new versions to system either because it will download them from the central maven repo it they arn't in system.
If it starts up without a data folder, it will install features & versions listed in org.apache.karaf.features.cfg
One would expect to be able to delete the data folder, change the version in org.apache.karaf.features.cfg & start it up, but I tried that and Camel was broken. Unsure why.
I find it easier to deal with it using the management console.
Install the management console by dropping the following xml file into the deploy folder:
<features name="features-murray" xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.0.0 http://karaf.apache.org/xmlns/features/v1.2.0">
<repository>mvn:io.hawt/hawtio-karaf/1.5.7/xml/features</repository>
<feature name="murray" version="1" install="auto">
<feature>hawtio-offline</feature>
</feature>
</features>
Then point your browser at http://localhost:8181/hawtio and login with SMX/SMX.
From OSGI/Features add the your new feature version with the plus button:
mvn:org.apache.cxf.karaf/apache-cxf/3.1.12/xml/features
It may take some time to install, because it downloads it from the net. I found it bounced me out of the management console also, but after logging back in I could uninstall the old cxf 3.1.9. It again logged me out of the management console, but after logging back in I had Camel active and CXF on 3.1.12.
No testing though - goodness knows what else is broken.
I'm working on a ClickOnce app that's set to online-only. I publish it to an internal IIS server, with an HTML page in the same directory that contains this link:
The deployment looks like so, with all files except the HTML page generated by my project's publish target:
MyAppName
-> Application Files
-> MyAppName_2213_20_0_65
-> <The published files>
-> default.html
-> MyAppName.application
When I click the link, the app runs immediately without any confirmation prompt, and I see from the about box that it's the old version. When I browse to the file share and launch MyAppName.application by double-clicking on it in Explorer, I get the prompt asking me if I'd like to run it, and then it downloads and I get an error:
Unable to install this application because an application with the same identity is already installed. To install this application, either modify the manifest version for this application or uninstall the preexisting application.
As part of the build process, I set the InstallUrl property of the project to http://ourserver/MyAppName/MyAppName.application. Is that wrong? Should it be the HTML page that contains the link? How is it determining the "identity" that's generating a conflict?
Since the app's online-only, it's not installed and doesn't show up in the Programs and Features control panel (and therefore that part of the error message doesn't apply).
I'm new to ClickOnce, so let me know if I left out some helpful information.
Update
If I run mage -cc from a Visual Studio command prompt, the new version launches instead of the old one.
Update 2
As I poked around more, I'm seeing something that looks wrong, and could be the problem. I see the following two lines in my MyAppName.application file (the deployment manifest):
...
<assemblyIdentity name="MyAppName" version="1.0.0.0" ...
...
<dependency>
<dependentAssembly dependencyType="install" codebase="Application Files\MyAppName_2213_20_0_65\MyAppName.exe.manifest" size="82044">
<assemblyIdentity name="MyAppName.exe" version="1.0.0.0" ...
...
You can see the mismatch above. It's deploying to MyAppName_2213_20_0_65, but it thinks the version number of the exe is 1.0.0.0. I'm not sure why it thinks that. My project includes a file that gets generated as part of the build with this line:
[assembly: AssemblyVersion("2213.20.0.65")]
Then, to set the published version number, I have this in my csproj file:
<Target Name="BeforePublish">
<GetAssemblyIdentity AssemblyFiles="$(TargetPath)">
<Output TaskParameter="Assemblies" ItemName="MyAppAssemblyInfo" />
</GetAssemblyIdentity>
<PropertyGroup>
<ApplicationVersion>%(MyAppAssemblyInfo.Version)</ApplicationVersion>
<InstallUrl>$(INSTALL_URL)</InstallUrl>
</PropertyGroup>
</Target>
Does the assembly version listed for my executable even matter? If it does, why is it stuck on 1.0.0.0, and could that be affecting the download of updated versions?
My second update put me on the right track. The problem was indeed the incorrect version number for the assemblyIdentity attributes. To fix it, I'm no longer using a BeforePublish target. Instead, I'm passing in the ApplicationVersion when I call MSBuild:
"%msbuild_path%" MyAppName.csproj /target:Publish /p:ApplicationVersion=%VERSION%
Can I put an MSI file or ISO image into a Chocolatey package?
So when I choco install foo, it won't download the MSI from another URL, but take the file from inside the package?
Yes, this is definitely possible. This is actually exactly what the ChocolateyGUI package does. You can see its .nuspec file here:
https://github.com/chocolatey/ChocolateyGUI/blob/develop/nuspec/chocolatey/ChocolateyGUI.nuspec
<?xml version="1.0"?>
<package>
<metadata>
<id>chocolateygui</id>
<version>$version$</version>
<title>Chocolatey GUI</title>
<authors>Chocolatey</authors>
<owners>Chocolatey</owners>
<projectUrl>https://github.com/chocolatey/ChocolateyGUI</projectUrl>
<projectSourceUrl>https://github.com/chocolatey/ChocolateyGUI</projectSourceUrl>
<packageSourceUrl>https://github.com/chocolatey/ChocolateyGUI/tree/develop/nuspec/chocolatey</packageSourceUrl>
<iconUrl>https://raw.githubusercontent.com/chocolatey/choco/master/docs/logo/chocolateyicon.gif</iconUrl>
<licenseUrl>https://raw.githubusercontent.com/chocolatey/ChocolateyGUI/develop/LICENSE</licenseUrl>
<bugTrackerUrl>https://github.com/chocolatey/ChocolateyGUI/issues</bugTrackerUrl>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>
Chocolatey GUI is a nice GUI on top of the Chocolatey command line tool.
## Features
* View all **installed** and **available** packages
* **Update** installed but outdated packages
* **Install** and **uninstall** packages
* See detailed **package information**
## Notes
This package will only work correctly on Windows 7 SP1 through Windows 10 (1708) or Windows Server 2008 R2 SP1 through Windows Server 2016, and requires .NET Framework 4.5.2 at minimum.
</description>
<summary>A GUI for Chocolatey</summary>
<releaseNotes>
All release notes for Chocolatey GUI can be found on the GitHub site - https://github.com/chocolatey/ChocolateyGUI/releases
</releaseNotes>
<tags>chocolateygui chocolatey admin foss</tags>
<dependencies>
<dependency id="Chocolatey" version="[0.10.3, 0.11)" />
</dependencies>
</metadata>
<files>
<file src="chocolateyInstall.ps1" target="tools"/>
<file src="chocolateyUninstall.ps1" target="tools"/>
<file src="..\..\BuildArtifacts\ChocolateyGUI.msi" target="tools"/>
<file src="..\..\LICENSE" target="tools\LICENSE"/>
<file src="VERIFICATION.txt" target="tools"/>
</files>
</package>
Then, as you pointed out, you would then use Install-ChocolateyInstallPackage to perform the installation, which would then use the local MSI within the package, rather than first downloading it. You can see the installation script for ChocolateyGUI here:
https://github.com/chocolatey/ChocolateyGUI/blob/develop/nuspec/chocolatey/chocolateyInstall.ps1
$ErrorActionPreference = 'Stop';
$toolsDir = "$(Split-Path -parent $MyInvocation.MyCommand.Definition)"
$fileLocation = Join-Path $toolsDir 'ChocolateyGUI.msi'
$packageArgs = #{
packageName = $env:ChocolateyPackageName
softwareName = 'Chocolatey GUI'
file = $fileLocation
fileType = 'msi'
silentArgs = "/qn /norestart /l*v `"$env:TEMP\$env:ChocolateyPackageName.$env:ChocolateyPackageVersion.log`""
validExitCodes= #(0,1641,3010)
}
Install-ChocolateyInstallPackage #packageArgs
Remove-Item -Force $packageArgs.file
You can do the exact same thing with an ISO image file, and there is a walkthrough on the established best practice for using that ISO file here:
How To Mount An Iso In Chocolatey Package
NOTE: If you are planning on pushing the package to Chocolatey.org, please bear in mind the size of the MSI/ISO file. If this is especially large, it is probably best not to include it within the nupkg, but rather use a download link.
Like Gary said, you can include arbitrary files in the package.
I'd emphasize that it's not a great idea. You have to download the package file itself (that's what happens when you choco install foo). Moving the MSI/ISO inside the package means you'll be downloading it with the package file and, depending on the size, slowing down feedback at the console.
Using the proper helpers and external URLs gives you a lot of great behaviors, least of which, is the download progress bar!
If file storage is a problem, there are many free options including: GitHub, Google Drive, DropBox, etc. If you're creating "internal" packages for your company, a network share can work with file:// URLs.
It's a WPF application, with Wix Installer.
I have resourceses folder and I want to include these files in the installer to put next to the executable. I solved generating a resources.wxs file with necessary information about the files under the resources folder using the heat tool. I managed to includ into the main wxs file. For that reason I modified the .wixproj file, adding a before build target action to generate the wxs and include it in the main wxs.
Concern: .wixproj is kind of hidden, there thing that you cannot modify from visual studio, like adding a before build action (pre build action is a different story)
Question: How can I extract the before build action into a separate file?
The before build action in the .wixproj:
<Target Name='BeforeBuild'>
<Exec Command='"%WIX%bin\heat" dir $(SolutionDir)resources -dr ResourcesDir -var var.ResourcesDir -cg ResourceFilesGroup -gg -g1 -sfrag -srd -out $(ProjectDir)Resources.wxs' />
<ItemGroup>
<Compile Include='$(ProjectDir)Resources.wxs' />
</ItemGroup>
You can extract it into a separate file—most project file types do that already. That's how they provide common targets to all projects of a type. A .wixproj has this:
<Import Project="$(WixVersionTargetsPath)" />
To augment your own, simply:
Create an XML file like:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name='BeforeBuild'>
<!-- tasks -->
</Target>
</Project>
Add an Import element inside the Project element and refer to that file:
<Import Project="custom.targets" />
If such a file primarily has Target elements, the convention is for it to have the file extension ".targets".
But there are two drawbacks with Visual Studio:
Visual Studio caches all the project file dependencies and runs the MSBuild internally. So, it you edit the external file, it won't be part of builds using Visual Studio until the project is next loaded. To quickly unload and reload a project, use the project context menu in the Solution Explorer. Workaround: Call MSBuild yourself.
When Visual Studio loads a project, if it includes non-standard external files, it gives a warning. (You can disable it per user by project file path, in the registry, if I recall.)
As an alternative to calling heat directly, you might want to look at the Harvest* targets that WiX provides. Note: As the documentation says, you don't invoke them directly (they're already invoked by the Build target); You simply add items to the ItemGroup they process and set properties they use.
A coworker of mine has this problem, apparently after installing Re#, which seems totally irrelevant. But perhaps it isn't.
Could not load file or assembly "SqlManagerUi, Version=9.0.242.0..." or one of its dependencies. The module was expected to contain an assembly manifest. (mscorlib).
Why is this?
Thanks
I was with a similar problem, i could not open my SQL Server Management Studio.
This steps works for me:
In file C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe.config, erase the item <NgenBind_OptimizeNonGac enabled="1" />.
Example:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<!-- ...snip... -->
<runtime>
<!-- ...snip... -->
<!-- Remove this line (~line 38) -->
<NgenBind_OptimizeNonGac enabled="1" />
<!-- ...snip... -->
</runtime>
<!-- ...snip... -->
</configuration>
I hope this helps.
Reinstalling the .Net framework didn't help me, but these next steps did. I had to completely uninstall and reinsall the shared components, but it's pretty hard to find out how to do that.
Make sure you have the installation media handy. In my case that's the unzipped folder from the downloaded SQLEXPRWT_x64_ENU ed 2014.exe
First, through your Control panel -> Uninstall a program, find 'Microsoft SQL Server 2014 (x64)'.
Right-click and select Uninstall/Change.
When you're presented with a dialog with the options to 'Add', 'Repair' or 'Remove' the product, select the last (don't worry, your SQL Server won't be touched if you follow these steps carefully.
From the initially blank drop-downlist select << Remove shared features only >>
Follow all steps from there, and you are now able to reinstall the shared features.
Management studio requires the .Net framework. Try removing/reinstalling it.
was there any installing/uninstalling of VS involved? Don't get me started on SQL 2005 and VS intall conficts.