Background
I am utilizing the following:
VS 2012
.NET 4.5 apps including an MVC4 app, a C# Domain app, and NUnit projects.
A custom MSBuild File
CruiseControl.NET running on a build server
I have the following build targets:
Clean: deletes the buildartifacts directory
Init: creates a blank buildartifacts directory
Compile: compiles the solution
Test: runs NUnit Tests
Package: creates a ZIP package for deployment
Deploy: Deploys package to a remote IIS Server
Problem
When I run the build from my local machine, it packages and deploys perfectly.
When CCNet runs the same build target, the files appear to be deployed
Attempted Resolutions / Potential Leads
I have run the same target in PowerShell from both machines and have seen no errors or warnings on either.
Because I tell CCNEt to override the framework to point it to the .NET 4.5 files I've copied to the build server, I made my local machine point to the same files when running MSBuild but my local build still worked and deployed.
In Visual Studio, I have ensured that all content files are marked with a Build Action of "Content" and a Copy to Output setting of "Copy Always".
The Code
Available in a gist at https://gist.github.com/53ef2a63931d190593f6
(file has been scrubbed, app name & credentials replaced, etc.)
It turns out, this was a completely unrelated issue.
After doing a diff of both build logs, I noticed that the build server working copy contained old files that no longer existed. This led me to discover that the issue ended up being that the repository wasn't being updated.
CCNet was receiving a subversion error that wasn't registering as an error
As a result, I was never getting the latest version of the repository, and so all files were broken.
The error is related to this StackOverflow question, regarding a sqlite error when attempt to use tortoisesvn to update. The solution in my case was to simply delete the build server's working copy, recreate the folder, and perform an svn checkout.
Related
We have for a while been building various web projects with AzureDevops and self hosted build agents.
Today I had to add a new build, consisting of a windows service written in .net core 3.1. This service has to be installed by our customers, so we have to provide it in a friendly installable way. As some of our developers were already used to handle MSI/*.vdproj projects, they added a vdproj into the *.sln to manage that. On a developper machine, this is not a problem even with VS2019: you just have to use the relevant VS studio extension...
But when it comes to building that in a CI/CD context, this becomes a real challenge. I quickly understood that we can't use MSBuild at all for that and found some alternative using directly Visual Studio (devenv)... Inspired by this thread (still opened), I came up with the following command line:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\devenv" [...]\MySolution.sln /build "Release" /Project MyInstallationProject
This worked fine both on my developer machine and even on the build agent machine. But when I add it into a build pipeline as a command line task, it seems to hang, and after a while I get the following result for the job:
##[error]The job running on agent <MyAgent> ran longer than the maximum time of 60 minutes. For more information, see https://go.microsoft.com/fwlink/?linkid=2077134
What can I do to make it work?
What are the best practices for generating a self installable in a CI/CD context? (Is MSI still relevant? )
As a workaround, you can try to install the extension Build VS Installer and use the task DutchWorkz - Build VS Installer(s) to build Visual Studio Installer Project in Azure Pipelines.
Here are some tickets(ticket1, ticket2) with similar issue you can refer to.
I am creating an ASP .Net Core (2.0) MVC application within Visual Studio 2017 which was working absolutely fine.
After turning off my computer yesterday and coming back to my application today, I now receive this browser error when I start the application in chrome without debugging.
Running dotnet run within the directory of the application, I can access the site just fine. It is just when I run it via Visual Studio/IIS Express I get this error.
HTTP Error 502.5 - Process Failure
The application builds and compiles just fine. I have also cleaned the solution.
Looking in the event logs I find:
Application 'MACHINE/WEBROOT/APPHOST/MYAPP' with
physical root 'C:\Users\Ben Hawkins\Desktop\Development Folder
\Dev\Website\Version_2\MYAPP\MYAPP\'
failed to start process with commandline 'C:\Program Files
(x86)\Microsoft Visual
Studio\2017\Community\Common7\IDE\Extensions\Microsoft\Web
Tools\ProjectSystem\VSIISExeLauncher.exe -argFile "C:\Users\Ben
Hawkins\AppData\Local\Temp\tmp3547.tmp"', ErrorCode = '0x80004005 :
0.
Within my output window in Visual Studio 2017 I recieve this message under
ASP NET CORE WebServer
Failed to initialize CoreCLR, HRESULT: 0x80131534
What I have tried:
Cleaning the solution, rebuilding etc
Restarting the computer
Trying to launch another application. (Same result)
Created a new application from scratch. Same result.
Repairing Visual Studio Community 2017. Same result.
Stopping/Closing IIS Express
My setup was working perfectly yesterday and suddenly is not.
Thank you for your time. I hope we can find a solution.
We finally found the issue! After logging on to the machine as a different user, we saw a warning that the main user had ignored initially. There was a 0 byte file in the root of the directory named "Program" with no file extension. It appears that this causes some sort of issue when VSIISExeLauncher.exe is invoked through Visual Studio. (Note it would work if executed from the command prompt). After deleting the file, everything worked!
We do not know how this file was placed there for certain, but suspect it was some sort of copy error when the user was pulling in files from his old hard drive.
I don't know if anyone else will come across this, but if so hopefully this helps!
Maybe you need install previous versions of .NET Core, isn't it? I installed here and it works now. I had only .NET Core 2.0 installed and I realized that applications with 1.1 stopped so when running. In Windows' event logs I've had the same error registered.
Try to change the IISExpress to IIS by creating new IIS profile and change the Lunch to IIS. It resolved my problem.
I have hit a very similar issue with ASP.net Core 2.0. I had copied my VS project to a new one, and I was getting this error message.
After doing some research, I was able to determine that the nlog.config file was not copied into the bin > Debug > net461 folder. Once I did this, I was able to run my application.
I found it by running dotnet run from the command line on my project where the csproj files live.
Had same issue yesterday (windows 10).
Solved it this way:
Update Microsoft.AspNetCore to latest (Nuget manager - 2.1.3)
Make sure the sdk also updated to latest version. if not, update it manually from Nuget console like this:
Install-Package Microsoft.NETCore.App -Version 2.1.3
Download and install latest ASP.NET Core/.NET Core: Runtime & Hosting Bundle
from here
Same problem with version 2.2. Reinstalling .NET Core SDK fixed the problem for us.
In my case, my project was setup as a website in IIS and the file "bin\IISSupport\VSIISExeLauncher.exe" was missing in the project's directory.
I simply selected "IIS" when debugging the project in Visual Studio 2019 and it generated the missing file. It also generated 2 text files (IISExeLauncherArgs.txt, pidfile.txt) in the IISSupport folder, made changes to my web.config file, and my project ran successfully.
After that I was able to access the local website that was setup in IIS without running it in Visual Studio.
I am working with .net core 2.0 console application. I need to run this console app using command prompt.
Like,
MyApp.exe arguments
I published the console app using below command to generate .exe :
dotnet publish -c Release -r win10-x64
It creates multiple .exe file,
1) \bin\Release\netcoreapp2.0\win10-x64
2) \bin\Release\netcoreapp2.0\win10-x64\publish
I believe both are same and I can use (2) as published version of the app. Correct me if wrong.
I am not sure why it generates .exe at (1) and does not contain bunch of dlls at there.
What is the difference?
anyone can give me more information about this?
The first one is still a framework-dependent deployment, it used when you call dotnet run -r win-x64. It resolves and configures the shared framework via the information in .runtimeconfig.json and your PATH environment variable and locates the DLLs via a values in the .runtimeconfig.dev.json and .deps.json based on your global packages cache (=> specific to your machine and user).
For deploying self-contained applications, the publish folder contains all the necessary assets. The host uses the local dlls instead of the shared framework and as well as the necessary DLLs.
I am a newbie to TeamCity and Octopus Deploy.
My project has many branches that uses different version of 3rd party dlls. The problem i am facing is when i am switching branches in TeamCity and build the code it deploys (using Octopus Deploy) the code successfully but it doesn't clear the target folder.
Like the Bin folder holds all the dll required by the project so when i switch branches and build using TeamCity and deployed using Octopus Deploy the previous dll are not removed and the application shows following error due to existence of same class in multiple dlls
The call is ambiguous between the following methods or properties
How can i fix this issue?
There is a couple of ways to do this. It really depends on how you are versioning and deploying your code from TeamCity to Octopus. If you are using NuGet pacakges and providing a version for each package, then having Octopus trigger a deployment based on the new package version, you will have a new directory for each deployment, and you won't have this problem at all. That being said, here are a couple of ways to fix this in your current workflow.
Use a Powershell script as the first step in your deployment, and have that script clean the deployment directory.
Use a "Custom Installation Directory" and set the "Purge this directory before installation" flag.
To enable the "Custom Installation Directory," click on "Enable features," on the bottom of your deployment step, and check "Custom installation directory"
Then configure your directory path and check the "Purge this directory before installation" option.
I have an application that loads user controls into .NET web application. When I compile and test the application locally on my dev machine it works on my machine. The project builds successfully using MSBuild on our build server. However when I deploy the dll generated by MSBuild on the build server I get the following error when the application loads the control:
BC30456: 'CreateResourceBasedLiteralControl' is not a member of 'ASP.usercontrols_somecontrol_ascx'.
I took a look and compared the dll generated on my machine and compared it(looked at the file size) with the one created by the build server and noticed
a difference in the file size. This is confusing considering the code being built locally and on the build server is IDENTICAL. I manually compared each file by hand. So my question is: What is causing this error? What would be different between MSBuild's compilation of the code and what is going on in Visual Studio when compiling the code?
You've got a versioning issue. Some assemblies are different on your target machine than on your dev machine. I'm afraid you're going to have to do some digging to hunt it down, since this error message is entirely unhelpful. Really it's pointing you in the wrong direction since the problem isn't in your assembly. It's probably caused by something in your project References. Have you got some 3rd party tool or SDK on your dev machine that hasn't been updated on the server yet?
The last time I saw this was when I had built a DotNetNuke module that was built against a newer DotNetNuke.dll assembly than my server had.
If you compile that as dll.
Try delete App_Code.dll in bin folder.