I have a few repositories in Mercurial with the following structure:
Core
Integration
Admin
MyApp
From the MyApp repo, I want to include Core and Integration.
I add those as a sub-repo to MyApp, and place it inside an Externals folder.
Folder structure for MyApp looks roughly as this:
MyApp
- BusinessLogic
- DataAccess
- Externals
-- Core
-- Integration
- Web
- packages
The problem has got to do with the packages folder. I use package restore in all solutions, and NuGet downloads all packages fine. The folder contains the packages that my external projects rely on.
Only problem is, that the relative path from Core and Integration to the packages folder is now wrong.
Is there any way I can solve this?
I think you can fix it manually, your references should have relative hint path which starts with ../../packages. But to avoid this in future All you solutions which include this projects must have the same structure.
For example for other solution you have structure like:
MyOtherApp
- BusinessLogic
- DataAccess
- Externals
-- SubFolder
--- Core
--- Integration
- Web
- packages
If in this case you add nuget package to Core project, reference will be ../../../packages/.... And Core will be broken in other solutions again.
Other solution is make package from Core and Integration projects and use them in other solutions via nuget. My team uses for this TeamCity, it can pack projects, publish nuget packages and work as nuget feed out the box.
If you still want to keep it as a sub-repository (as opposed to referencing the projects as NuGet packages) you can modify the the hint paths to always search the solution directory.
For instance, I changed
<HintPath>..\..\packages\Moq.4.2.1312.1622\lib\net40\Moq.dll</HintPath>
to
<HintPath>$(SolutionDir)packages\Moq.4.2.1312.1622\lib\net40\Moq.dll</HintPath>
Related
I have a solution with many projects, and we are migrating to .NET SDK style projects, but for now we have a mix of .NET framework style projects and .NET SDK style projects.
We are also migrating to GitHub actions, and this solution was building without errors previously, but the restore action started failing when dotnet was updated from 6.0.300 to 6.0.400 (update: I tried targeting 6.0.300 specifically in the setup-dotnet action, but it's throwing the same errors, so I'm not sure what changed to cause it to fail like this when it was working before.)
I updated our local action server to 6.0.400, and when I run the command dotnet restore ./path/to/solution.sln it is restoring the NuGet packages for just the .NET SDK style projects as expected.
dotnet is installed with this GitHub action
- name: Setup .NET
uses: actions/setup-dotnet#v2
with:
dotnet-version: 6.0.x
and restore is being called with this GitHub action
- name: Restore dependencies
run: dotnet restore ${{env.SOLUTION_FILE_PATH}}
and when dotnet restore is being run from the GitHub action, I am getting the following error error MSB4057: The target "Restore" does not exist in the project. for all of the .NET SDK style projects. It's as if it's trying to restore NuGet packages using the older .NET Framework style NuGet packages. This is very different than what I've seen before and is unexpected. I have a separate action for calling nuget restore ./path/to/solution.sln for restoring packages for the .NET framework style projects, and I'm expecting dotnet restore to only restore the .NET SDK style projects.
Has anyone else run into similar problems with dotnet 6.0.400? Are there better options for restoring NuGet packages in GitHub actions?
I'm not really sure where to look next because running the command line commands locally work exactly how I would expect them to, and it only behaves oddly when getting called from GitHub actions.
Update:
I've been able to reproduce the failure locally by running the dotnet version that is being installed locally as part of actions/setup-dotnet#v2
If I run dotnet restore ... from the global install location C:\Program Files\dotnet\dotnet.exe then I get the following output which is what I expect
Determining projects to restore...
Restored C:\actions-runner\_work\MySolution\MySolution\src\FirstSdkProject\FirstSdkProject.csproj (in 335 ms).
Restored C:\actions-runner\_work\MySolution\MySolution\src\SecondSdkProject\SecondSdkProject.csproj (
in 357 ms).
If I restore from the locally installed dotnet at C:\Users\MyUser\AppData\Local\Microsoft\dotnet then I get the unexpected output that I'm getting in the GitHub action
Determining projects to restore...
Determining projects to restore...
C:\actions-runner\_work\MySolution\MySolution\src\FirstSdkProject\FirstSdkProject.csproj : error MSB4057: The target "Restore" does not exist in the project.
Nothing to do. None of the projects specified contain packages to restore.
Determining projects to restore...
Nothing to do. None of the projects specified contain packages to restore.
Nothing to do. None of the projects specified contain packages to restore.
Determining projects to restore...
C:\actions-runner\_work\MySolution\MySolution\src\SecondSdkProject\SecondSdkProject.csproj : error MSB4057: The target "Restore" does not exist in the project.
Nothing to do. None of the projects specified contain packages to restore.
Nothing to do. None of the projects specified contain packages to restore.
Determining projects to restore...
Nothing to do. None of the projects specified contain packages to restore.
Nothing to do. None of the projects specified contain packages to restore.
Nothing to do. None of the projects specified contain packages to restore.
Nothing to do. None of the projects specified contain packages to restore.
Comparing the information on dotnet.exe, they are the exact same version of dotnet and using a file compare program they are binary the same, and the folders they are in are seemingly the same as well with only a few minor differences. Why would running restore have two very different outcomes just running from different locations?
One of the main differences between a .NET Framework project and a .NET SDK project is how NuGet package references are managed. With .NET Framework projects, NuGet references are managed in packages.config. To build and restore including packages.config references you need the following
msbuild -t:build -restore -p:RestorePackagesConfig=true ./path/to/solution.sln
If you don't have mixed projects and they all follow the .NET SDK csproj format, then you won't have any packages.config references and you can build and restore with this.
msbuild -t:build -restore ./path/to/solution.sln
The option RestorePackagesConfig is only available on msbuild 16.5+ https://learn.microsoft.com/en-us/nuget/reference/msbuild-targets#restoring-packagereference-and-packagesconfig-projects-with-msbuild
Recently I deployed some projects like trntv/yii2-starter-kit and so on.but all applications are publishing assets on '#vendor/bower' instead of'#vendor/bower/bower-asset'. I have read the question Yii2 Composer manage package in bower and bower-vendor and solved it . but I still feel confused about the directory vendor/bower/bower-asset.
What's the part does bower/bower-asset play in php application? it is not a composer package but many theme store in there. Furthermore, bower is a dependency management for javascript just like Composer for PHP , but how does it solve dependency for js package by PHP on this occasion that I have not install node.js environment?
The idea of Composer Asset Plugin is to download Bower / NPM packages and manage their dependencies without having Node JS, Bower and NPM installed (through PHP / Composer). Also it adds possibility to add JavaScript dependencies for PHP packages that use JavaScript libraries.
See for example yii2-bootstrap Yii2 extension (PHP) has a dependency on Bootstrap (JS + CSS):
"bower-asset/bootstrap": "3.3.* | 3.2.* | 3.1.*"
When you run composer install or composer update, all JS dependencies will be installed to vendor/bower folder.
This is built into the core, but very ambiguous, receives a lot of criticism and there are plans to remove it in 2.1.0 (as far as I remember, it was included before release of 2.0 even it was unstable). Unfortunately this is required and there is no normal way to disable it.
You can read more info on the extension's Github page.
As for folder name, it should be named bower, not bower-asset, if you installed everything correctly.
It's named like so automatically, make sure you have the latest version of plugin:
composer global require "fxp/composer-asset-plugin:~1.1.1"
I'd recommend to even switch to:
composer global require "fxp/composer-asset-plugin:*"
If you have problems or errors, execute:
composer global remove "fxp/composer-asset-plugin"
Then reinstall it again, delete vendor and composer.lock in your application folder and run:
composer install
I'm basically trying to figure out what I need to do, to make an MVC project (created in Visual Studio 2013) to behave like a fresh MVC project created directly in Visual Studio 2015.
What I've noticed is that I see more interesting things in Visual Studio 2015 with a newly created project, and I'm sure some of these would be useful, but I can't figure out the magic to get them enabled. I've tried doing some googling but unfortunately keep finding tutorials for VS2013 support which isn't what I'm after, I specifically want to leverage the new VS2015 features. Things that I've spotted so far:
Dependencies
How do I enable the dependency view? I've tried copying a bower.json file from a new project, but even after a restart in VS2015 I don't get this dependencies tracker.
Task Runner
How do I enable the task runner? I tried creating a Gulpfile.js but I get an error in the output window gulp is not recognized as an internal or external command. I don't get this in a brand new solution, but it reads as though gulp isn't installed on my machine?
How do I enable the dependency view?
This isn't possible; the Dependencies node is part of the DNX project system and is only available in new projects.
How do I enable the task runner?
In addition to adding the gulpfile, you must add a package.json file, and add "gulp" to its devDependencies section. Other tools you'll be using in Gulp should be added here as well. You can use a new ASP.NET 5 project as an example.
You may want to add a bower.json file as well. Bower components will be downloaded to a bower_components folder, which will be hidden by default in the old project system. Adding Bower.json from the New Item template will also add a .bowerrc file that moves the package download location to wwwroot/lib. Probably not what you want for the MVC project; you could change this to just lib instead, or delete the .bowerrc. While the hidden bower_components folder is harder to work with, it's omitted from checkin in git, which is probably what you want.
when you generate a yeoman project, do you commit the node_modules that is generated into your code repository?
It seems like it is necessary for another developer to check out a project and develop from it, but it seems like a lot of files to commit which seem unrelated to a project itself.
You can just run npm install to get the dependencies installed. However there are multiple benefits to committing your dependencies, which you can read about in this blog post:
Checking in front-end dependencies (for Bower, but applies to npm too)
I have a solution that is primarily developed in Visual Studio 2012. I would like to develop in MonoDevelop without major incompatibilities.
Thus far, I have installed mrward's nuget addin for MonoDevelop and things work if I manually add each package in packages.config through that interface. However, this is highly onerous. This addin doesn't have support for automated package restore as of this writing.
I downloaded nuget.exe from CodePlex ("NuGet command line utility", as it's labeled). I use a simple find/xargs combination to install all required packages:
find . -name packages.config | xargs -I '{}' mono nuget.exe install '{}'
This creates several dozen directories in the directory from which it is run instead of putting things under packages/ as expected, and it also doesn't touch the project files so MonoDevelop still thinks that it should be looking for package references in the directory from which MonoDevelop was started.
I therefore opened MonoDevelop from the working directory that contains all of these package folders, and I still get invalid references. I think this is probably because the project is looking for package_name/ reference, but the folders are name package_name.version/ in the working directory.
Any suggestions for a sane, simple way to interact with this solution? I'm next going to try modifying my shell command so that it automatically drops to project/packages and runs nuget from that directory.
Did you try using the -o command line parameter with NuGet.exe? You can use that to get the packages to install into a particular packages folder.
The NuGet addin for MonoDevelop supports package restore from version 0.6 or above. Right click your project and select Restore Packages. This will download all the packages defined in your packages.config for all projects in the solution. It uses NuGet.exe to do this.
Another way to get this working is to use the custom NuGet MSBuild target so the package restore happens at build time when using xbuild. It would require some manual editing of project files though. Under the covers the custom MSBuild target just uses NuGet.exe with a similar command line to what you have already just with the output directory option specified. So I would try the command line approach since that will be less work.
You would have to get the following files from the NuGet repository on codeplex:
NuGet.exe
NuGet.targets
NuGet.config
Put these in a directory somewhere. Typically these are put in a .nuget directory in the same directory as your solution file. Then you need to edit your project files to include the NuGet.targets file and also define the SolutionDir property. So something like this:
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\..\</SolutionDir>
<Import Project="$(SolutionDir)\.nuget\NuGet.targets" />
You will also need to enable package restore on your machine. You can do this using the NuGet addin for MonoDevelop in the Options dialog. Under Linux this is available from the Edit menu under Preferences. Then look in the NuGet - General options and there is a checkbox for enabling package restore.
There is an example project on GitHub created by Jonathan Channon which uses package restore and works when building with xbuild inside MonoDevelop. There is also an issue on GitHub about using NuGet restore on Linux which might be helpful.
Update: 2014-05-14: NuGet addin for MonoDevelop now supports package restore.