I have a web app in dot net along with other projects. when i open the .sln file and publish the web project, it does. But, when I try to publish the web proj using command line and .csproj, it gives an error. "Nothing to do. None of the projects specified contain packages to restore."
I got this after converting my csproj to vs2019 format and running dotnet test. The solution was to ensure i had the right test adapter and framework. My csproj files had both the old Microsoft.VisualStudio.QualityTools.UnitTestFramework reference and the new MSTest.TestAdapter + MSTest.TestFramework + Microsoft.NET.Test.Sdk.
I kept the new ones and my tests were run.
I had this problem in a batch file I use to build a UWP component for release. The build command is
%MSBUILD% CartoType\src\main\single_library\uwp\CartoType\CartoType.sln -p:Configuration=Release;Platform=x64
where %MSBUILD% is the full path to msbuild. I first added an msbuild command with the -t:restore option and got the message reported by the original poster ('Nothing to do. None of the projects specified contain packages to restore').
The solution was to add this command before the command given above:
%MSBUILD% CartoType\src\main\single_library\uwp\CartoType\CartoType.sln -p:RestorePackagesConfig=true -t:restore
Related
On a Windows machine there is a GitLab-Runner run from a domain user with admin rights. When I log as this user and call dotnet build -c release to build an ASP.NET Core app, the dll has all the information from the AssemblyInfo.cs file. When I do the same as part of a CI job, the produced dll is missing all this information (for example the version number).
The AssemblyInfo.cs file is not part of the repository, instead, it is produced by a prebuild event (using gitWCRev.exe tool). However after running some tests I can see that the AssemblyInfo.cs is actually generated when the job is run by the runner.
Any help as to why the file is ignored and how to overcome this issue would be appreciated.
At first I thought that this might be related to Pre-build task of Visual Studio project fails in GitLab Runner issue, but I don't get any build errors.
On the same machine, I build a .Net Framework app which has the same AssemblyInfo setup, but is compiled using msbuild /property:Configuration=Release by the runner and the produced dll file has all the expected information.
It turns out the problem was partially related to the AssemblyInfo.cs file not being part of the repository.
SDK-style csproj normally don't list the files in the project, but figure them out based on the folder contents. When dotnet build was run, AssemblyInfo.cs wasn't present in the project directory (GitLab-Runner usually clears out files not present in the repository before starting a job/pipeline), so build tools had no idea they needed to load it. It made no difference that the file was being created by the build tools.
The solution proved to be creating an empty AssemblyInfo.cs file before running dotnet build. This way build tools knew they needed to compile it. Actual compilation still happened after prebuild events, so all the needed information was there.
I created the empty AssemblyInfo.cs file using PowerShell:
New-Item -Path "Properties/AssemblyInfo.cs" -ItemType File
Also, checking the build logs helped me finally figure it out. To get the build logs I've called build tools like this:
dotnet build -c release /flp:v=diag
The .Net Framework app didn't have this problem because it wasn't an SDK-style project. All the files needed for compilation were listed in the project file and build tools knew to load them, even if they were created during the prebuild event.
I am working on an ASP.NET Web API 2 project with .NET target framework 4.6.1. I am trying to setup github workflow for my repo. When the dotnet restore command is run, it throws an error like below.
I am getting the same error if I run the same command in from command prompt inside my project. Also if I run dotnet build, it shows below error.
The project builds fine from Visual Studio but not working from command line or github workflow yml. Can anyone please point me on what am I missing?
The project builds fine from Visual Studio but not working from command line
Check which sln file Visual Studio is using to build your project.
Since I don't see any sln/csproj in your GitHub repository, it is also possible that you have a .gitignore which would prevent adding those in the first place.
DOTNET Restore does not support pacakges.config https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-restore
So you have to move the nuget package references to csproj file itself
Here is a great comment on how to do that https://stackoverflow.com/a/65701746/8318698
Note: check that if multiple projectGuid is there on csproj at the end of the steps
After that you will be able to use dotnet restore without a hitch.
We are attempting to install a clean build of the newest version of Kentico (12) on Azure, using Kudu, in DEBUG configuration. We traditionally accomplish this by setting SCM_BUILD_ARGS to -p:Configuration=Debug, and all is well. But for some reason in this newer version, the project fails to compile, and I see that this is the command being run:
"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" "C:\Users\User\Documents\GitHub\Project\CMS\CMSApp.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="C:\local\Temp\8d6d315018f5ff9";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false /p:SolutionDir="C:\Users\User\Documents\GitHub\Project\.\\" -p:Configuration=Debug
Notice both Configuration=Release and Configuration=Debug. The compilation errors are things like Invalid expression term 'string' on the following line of code:
bool licenseOK = LicenseHelper.CheckLicenseLimitations(FeatureEnum.Ecommerce, out int skuCount, out int maxSKUCount);
This doesn't highlight at all in Visual Studio in Debug or Release mode. I am also able to reproduce locally (as shown in my paths above), and if I change the two configurations to both be the same (regardless of whether I choose Debug or Release), it compiles just fine.
What I know I can do is create my own custom deployment command script file as a work-around, but I guess I don't understand why the above MSBUILD command isn't working in the first place.
Any ideas as to why this would work great for all of my ASP.NET projects prior to this one? One thing I know is that Kentico recently included the Roslyn compiler, which I am unfortunately not that familiar with - could that be part of the issue?
UPDATE #1: It appears all of the compilation errors have to do with code that is only valid in C# 7.0. That could be a clue.
It all came down to the fact that the newer versions of Kentico had code that was only valid in C# 7, and required MSBuild 15 to compile. Here's how I was able to set up Kudu:
Add a file named .deployment in the root of my repo, containing only the contents below. This tells Kudu to use a custom deployment script.
Download the deploy.cmd file from my Azure App Service via FTP to the root of my repo, and update it per https://github.com/projectkudu/kudu/issues/2350#issuecomment-373817740 to use the MSBuild 15 path. Details below.
.deployment file contents
[config]
command = deploy.cmd
deploy.cmd updates
1 - Add -MSBuildPath "%MSBUILD_15_DIR%" to nuget call. Example:
nuget.exe restore "{your .sln file path}" -MSBuildPath "%MSBUILD_15_DIR%"
2 - Replace %MSBUILD_PATH% with %MSBUILD_15_DIR%\MSBuild.exe in both occurrences under step 2. Build to the temporary path
This was all that was needed in order to get the build to complete.
As Keith mentions, it was a compatibility issue with C# 7.0 that Kentico 12 uses. This SO thread mentions that you need to run MSBuild version 15 for C# 7.0 code. I ran a similar debug command for my local Kentico 12 project using MSBuild 15, and it succeeded.
I am using VS2015, and MSBuild 14.
My solution has many projects, but three of them are old ASMX web sites. The ASMX website "projects" don't have their own project files, but are detailed in the XML of the solution file itself.
The solution builds fine inside Visual Studio.
However, when I try to build on the command line with MSBuild, I am getting an error message. Here is my MSBuild command:
C:\> msbuild MySolution.sln /t:MyAsmxProject
All the dependent projects (mostly c# class libraries) are built as I would expect them to be. Lots of output to the cmd window in which msbuild is running, until we get to the following action by msbuild:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /MyAsmxProject
-p MyAsmxProject\ -u -f -d -fixednames Precompiled\MyAsmxProject\
The whole thing bombs out here with the following error:
ASPNETCOMPILER : error ASPCONFIG: Could not load the assembly.
The property 'assembly' must be a valid assembly.
[C:\My\Long\Path\MySolution\MyAsmxProject.metaproj]
Now at first I didn't know what a "metaproj" file was, and was unable to find that file, but I did understand it to be an intervening project file created internally so that msbuild could operate on solution files. I discovered that I could see the metaproj file if I set the environment variable:
set MSBuildEmitSolution=1
And then re-ran the msbuild command. I now have metaproj files for both my solution and for my asmx project, which would appear to be the one referenced in the error message above.
These are both pretty dense msbuild files, but neither one of them have an XML node (element) named "assembly" and neither one of them have any XML nodes with the attribute or property "assembly" applied to them.
So I am unclear what this error is saying and how to fix it. And doubly unclear as to why it crops up with msbuild, but not with visual studio.
Any insights or suggestions most appreciated.
Although I don't fully understand why, I have found a solution.
Namely, if I run the command window in which I am doing the msbuild as an administrator, I don't get this error. This is an acceptable solution for me.
However.... it would still be great to understand more specifically what the error means, and why being an adminstrator makes the difference.
I have a solution which contains many class libraries and an ASP .NET website which references those assemblies.
When I build the solution from within the IDE, all assemblies referenced by the website end up in the bin directory. Great!
When I use MsBuild from the command line, all the referenced assemblies are not copied to the bin directory. Why?
My command line is simply:
msbuild.exe d:\myproject\mysolution.sln
I have found various references to this problem scattered around the Net - and I've just come across it myself. Apparently MSBuild on the command line isn't as good at tracing chains of dependencies as the IDE is.
So as I understand it, if A depends on B which depends on C, The command line may not realize that A depends on C.
The only solution I've found is to ensure that you manually set the project dependencies so that the ASP project references everything it depends on - don't expect it to be able to figure them all out on the command line. This has worked for me, although I only have 5 projects so it's not a bind to get going.
I hope this helps.
The issue I was facing was I have a project that is dependent on a library project. In order to build I was following these steps:
msbuild.exe myproject.vbproj /T:Rebuild
msbuild.exe myproject.vbproj /T:Package
That of course meant I was missing my library's dll files in bin and most importantly in the package zip file. I found this works perfectly:
msbuild.exe myproject.vbproj /T:Rebuild;Package
I have no idea why this work or why it didn't in the first place. But hope that helps.
Which msbuild are you referencing? Is it the right one?
I generally call like this (from a batch file):
%WINDIR%\Microsoft.NET\Framework\v3.5\msbuild.exe deploy.proj /v:n
In this example, deploy.proj is just a regular msbuild file that does some other stuff before and after calling msbuild on the .sln file.
I think this problem only occurs when your bin directory is not the framework's default for a solution.
I understand that msbuild uses each project set up to build it. If this is so, please go to each projects properties page and check the post build event command line arguments.
You could always use a copy task in MSBuild to pull your assemblies into the proper directory. I asked a question not to long ago and ended up answering it myself. It shows how you can setup your Copy task to grab output from another project and pull it into your target project:
MSBuild copy output from another project into the output of the current project
I haven't been using msbuild for ASP.NET, but aspnet_compiler. Though...I don't remember why. Sorry.
%windir%\Microsoft.Net\framework\v2.0.50727\aspnet_compiler -v \%~n1 -f -p .\%1 .\Website
You could make use of the Post-Build steps in project properties to copy the output for the project to a particular location.
This copies to an Assemblies directory in the same directory as the Sln file. I have this in the post-build step of all my projects.
md "$(SolutionDir)Assemblies"
del "$(SolutionDir)Assemblies\$(TargetFileName)"
copy "$(TargetPath)" "$(SolutionDir)Assemblies" /y
Known problem ffor MSBuild 3.5 and msbuild 4.5. I am using Msbuild 4 found at
c:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe <yourSolutionFile>.sln
It seems to solve the problem.
If I recall, MSBuild dosen't copy the referenced assemblies.
I've posted a "solution" a while ago:
http://www.brunofigueiredo.com/post/Issue-Tracker-part-IV-The-Build-Enviroment-using-MSBuild-(or-NAnt).aspx
Hope it helps.