I'm running Visual Studio 15 Preview, and started a new project: ASP.NET Web Application > ASP.NET 5 Empty. I then opened project.json and modified it to add AngularJS.Core 1.3.4 as follows:
"dependencies": {
"Microsoft.AspNet.Server.IIS": "1.0.0-beta1",
"AngularJS.Core": "1.3.4" // I only added this line
},
I see the package downloaded and added to my packages folder, but the nupkg file has a content folder (with the actual *.js files I want added), but those files aren't being added to my project. There are no error messages or warnings of any kind (at least none via the package manager log).
I have also tried running kpm --verbose install ... and kpm --verbose restore via the command line, and I don't see anything useful for solving this.
I know I can manage this manually, but am I missing something? Is this a bug, or am doing this wrong, or are my expectations incorrect? I'm new to this ASP.NET vNext stuff, and this is my first time jumping into it.
It doesn't. KPM currently doesn't do anything with packages that contain content/powershell scripts/transforms etc.
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'm building an asp.net application using VScode, scaffolding areas using "aspnet-codegenerator" command always fail because of missing files.
I tried to uninstall the tool and reinstall it again, but still the same error
Firstly, please try to check if MvcControllerWithContext.cshtml file does exist under that folder mentioned in error.
Templates file path on my computer
C:\Users\user_name_here\.nuget\packages\microsoft.visualstudio.web.codegenerators.mvc\verison_here(such as 3.1.4)\Templates\ControllerGenerator
Besides, if you indeed installed the dotnet-aspnet-codegenerator tool, but error still occurs, you can try this workaround:
copy Templates/ControllerGenerator and Templetes/ViewGenerator to the project folder
then rebuild the project and run your dotnet aspnet-codegenerator command to generate controller and view etc.
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 running Windows 7 Home Premium 64-bit.
I updated my .NET Core installation to the latest version 2.1.500 a few days ago.
Shortly after, I wanted to play with the source code for MS Build, so I cloned the MS Build git repo and ran their build.cmd file as instructed.
But it kept failing telling me it wasn't able to download the per-requisite .NET Core version 2.1.401.
C:\Source\Of\MSBuild> build.cmd
dotnet-install: Downloading link:
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
dotnet-install: Cannot download:
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
dotnet-install: Downloading legacy link:
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-dev-win-x64.2.1.401.zip
Exception calling "Invoke" with "0" argument(s):
"Failed to download
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-dev-win-x64.2.1.401.zip."
yada yada yada yada...
So I downloaded the zip file https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip manually, and unzipped it to find a dotnet.exe in it.
First thinking that it was a set-up file, I double-clicked it. It appeared and disappeared quickly.
Then, after a few failed attempts, I suspected it was indeed the SDK itself and wasn't an install-able set-up. So, I checked the folders in the unzipped file and they matched exactly the folders in my C:\Program Files\dotnet folder (see the picture at the bottom of this question).
So, now, I don't know how to have this version of .NET Core that I just downloaded (v 2.1.401) co-exist with the latest version 2.1.500. I do see that the C:\Program Files\dotnet\sdk\ folder has several versions exist side by side:
C:\Program Files\dotnet\sdk>dir /b
1.0.0
1.0.0-preview2-003131
2.1.500
NuGetFallbackFolder
So, should I just go ahead and mess around with my folders manually? That is, should I just copy and paste the folders I downloaded and merge them with what I have? See below.
The contents of the two folders needn't have to be merged. One must download the .NET Core installer instead.
Two issues need to be addressed in answering this question.
I had downloaded the binaries in a zip file and not an installer. I was led to install the binaries because the URL I saw on the console when I ran the build script pointed to the binaries and not to the installer.
.NET Core comes in two kinds of packages:
a. MSI installers; and
b. Zip files containing the binaries. These are useful when you want to hold a private copy of .NET core in your application. Just like NPM packages have private installations in contrast to public/global ones. Just like you hold private assemblies (CopyLocal = True) of the .NET framework within your application in contrast with references them from the GAC or the Reference Assemblies folder.
Look at this SDK download page on the Microsoft website. It lists both, the binaries and the installers for each version of the SDK and the runtime.
A Powershell script in the MS Build build process downloads the zip file containing only the binaries and it holds this version of the .NET Core privately. The version it is looking for is mentioned in the DotNetCliVersion property in the Version.props file.
From build1.ps
function Build {
if (![string]::IsNullOrEmpty($DotNetCoreSdkDir) -and
(Test-Path -Path $DotNetCoreSdkDir)) {
$env:DOTNET_INSTALL_DIR = $DotNetCoreSdkDir
}
else {
InstallDotNetCli
}
$env:DOTNET_HOST_PATH = Join-Path $env:DOTNET_INSTALL_DIR "dotnet.exe"
...
I have Solution A which has a .NET Core 1.1 class library project. In the Package properties I filled all NuGet fields and selected to create the NuGet upon successful build. This project builds just fine and the NUPKG is created. BTW How can I automatically copy the generated NUPKG to a local directory (my own repository)?
Then I have Solution B which is an ASP.NET Core 1.1 web application. In it I browse to my local repository (where I have manually copied the NUPKG built by Solution A) and install my SolutionA.MyPackage into the web application. VS.2017 says it was successful at installing it. I see it listed in the project's NuGet dependencies.
However, when I try to use ANY of the objects defined in that NuGet package I get a red highlight saying it is not found as if there was no NuGet or assembly reference to that DLL but there is!
What is causing this Visual Studio generated Nuget package to be installed and yet act as if it has not even been referenced?
UPDATE - CSPROJ TARGET
As for copying to my local repository, I added this to CSPROJ but it was not working (somebody had suggested it as I put it). I finally figured out why it did not work, the ItemGroup must be inside the Task.
<Target Name="CopyPackage" AfterTargets="GenerateNuspec">
<ItemGroup>
<MyPackageFiles Include="bin\Release\PackageId.*.nupkg" />
</ItemGroup>
<Copy SourceFiles="#(MyPackageFiles)" DestinationFolder="D:\My Repository\MyNugget\Publish" />
</Target>
UPDATE NuGet Inspection
I opened the NUPKG with NuGet Package Explorer and it shows this more or less:
content\
Properties\
launchSettings.json
Views\
Shared\
rest of my stuff here
contentFiles\
any\
netcoreapp1.1\
Properties\
launchSettings.json
Views\
Shared\
rest of my stuff here
lib\
netcoreapp1.1 (.NEtCoreApp, Version=v1.1)
MyPackage.dll
UPDATE 3
Since NuGet seems to have stopped working (used to work well earlier) I opted for using an Assembly Reference rather than a NuGet (for now). In this situation something odd happens, when coding I can reference ALL the objects in the referenced assembly (former NuGet) and therefore no compilation errors on the main project BUT when I then run the web application I get an internal error because it says
FileNotFoundException: Could not load file or assembly
'MyPackage, Version=0.0.3.0, Culture=neutral, PublicKeyToken=null'.
The system cannot find the file specified.
Unknown location
Which is strange because in the Solution Explorer I see the assembly reference and when I click on it (main application) I can navigate to all the objects that I have defined in that assembly. Why it cannot find it anymore?
It is working again (as it was before!). Today I could open the solutions but when I tried to download an extension (Tools | Extensions) I got an error message about an Access Denied or something like that. It has happened before since I installed to VS.2017.
Of all the Visual Studios I have used since 2002 this has been the most unstable! (and I have update 15.2).
When I saw this error happening again I knew how to get rid of it and thought, "hey, maybe that is what is keeping the NuGet package to be installed but not found or the problem with a direct assembly reference".
So I went to my C:\Users\AppData\USER\Local\Microsoft\VisualStudio\15.2* folder and removed it completely.
After that I the ACCESS DENIED issue went away with the side effect that I had to reinstall all extensions again. I attempted again to install my own NuGet, it did so successfully and as expected (was not happening during the long glitch) the objects were found and the web application worked again.