We're using CruiseControl.NET which invokes an MSBuild script. While debugging the build script, we make small changes constantly and run the build through the CruiseControl.NET web console running on IIS. Everything is just on one machine though since we're just testing.
I've noticed that some changes we make in the MSBuild script aren't picked up. Sometimes they push through, sometimes the server is a few versions out of date. Sometimes restarting IIS services does the trick. Sometimes not even that works.
Is anyone aware of what's happening in the background? Is there some cache we have to clear for web apps? Where could it be?
Edit: To clarify, all my stuff is on a single machine as I'm still in the testing stage. So I don't think source control should be an issue. My ccnet.config simply calls the MSBuild target. Here's a simplified sample:
<project>
<tasks>
<msbuild>
<executable>$(netFrameworkRoot)\MSBuild.exe</executable>
<projectFile>C:\MyProject\ProductBuild.proj</projectFile>
<targets>BuildProject</targets>
</msbuild>
</tasks>
</project>
ProductBuild.proj is a hand-coded MSBuild script that builds a lot of other .NET solutions and packages an installer with a vdproj.
It seems that changes made to my build script do not always take effect when I run a build on CruiseControl. I guess it would be safest to restart the CCNet service, but I was hoping I wouldn't have to interrupt currently running builds.
"run the build through the CruiseControl.NET web console running on IIS" As far as I know the Web Console does not do any building. It sends a message to either ccnet.exe or ccservice.exe, which ever is the on running and listening on port 21234 (unless specified to another port) But to try and get to your problem, Do you have your build project to always get latest? Is your MSBuild file in source control? What source control are you using? Are You changing the MSBuild file in the workspace on the build server? You should post a copy of your project here so we can try to determine the error? I can tell you that as far as CruiseCOntrol is concerned IIS and the web cache has nothing to with the actual compiling. Unless you are talking about the project you are building needs IIS?
Related
I'm trying to get one of our projects building on Visual Studio Team Services.
The issue is with candle.exe, specifying "MsBuild x86" the build gets as far as the call to candle.exe then it hangs (it gets there within minutes, then will hang until VSTS terminates the build amlost an hour later).
If I run it with "MsBuild x64" it runs as far as the first time, but fails because it can't find candle.exe
d:\a\1\s\Ref\Ext\WiX.3.5\Lib\wix2010.targets(1813,5): error MSB6003:
The specified task executable could not be run. The system cannot find
the file specified [d:\a\1\s\Configuration\install\Installer.wixproj]
While it complains about the wixproj, that file exists, and I'm fairly sure it's the candle.exe it can't find.
I'm not sure where to go from here.
Things I ended up doing to fix this.
Remove my locally installed version of wix (it was clouding the
issue)
Upgraded the version of wix that gets checkout with the repository on VSTS (yes we should be using NuGet I know).
Explicitly set a value $(WixToolPath)
Explicitly set the ToolPath to $(WixToolPath) when building the wixproj
Switch off ICE validation scripts for the build
The installers now run.
I have a ASP.NET Core app. I run the application by running the command
dotnet run
I'm seeing the following error in one out of five situations when I build this ASP.NET Core app.
C:...\error CS2012: Cannot open 'C:...\bin\Debug\netcoreapp1.0\AAA.Web.dll' for writing -- 'The process cannot access the file 'C:...\bin\Debug\netcoreapp1.0\AAA.Web.dll' because it is being used by another process.'
In addition to the above issue, I also see no updates that I make in the CSHTML file. I have to stop the dotnet run command, build the app again and then run the dotnet run command.
How can I fix these issues?
This may also help when running your aspnetcore app in IIS.
Add the following to your csproj:
<Target Name="PreBuild" BeforeTargets="PreBuildEvent">
<Exec Command="echo "App Offline" /a > "$(ProjectDir)app_offline.htm"" />
</Target>
<Target Name="PostBuild" AfterTargets="PostBuildEvent">
<Exec Command="del "$(ProjectDir)app_offline.htm"" />
</Target>
If it is on local and application is running on IIS, then in windows task bar before your date time, there should be a IIS Express Option. select IIS Express, select exit. Try running application again.
In my case, I got the same issue due to dotnet watch run command even after stopping the watch mode. Visual studio reported this error message :
The file is locked by: ".NET core Host (pid)"
killing the process with the pid fixed the issue.
When trying to kill the process using /taskkill /f /pid <number in the error> it was telling me the process didn't even exist.
I simply had to find .NET Core Host in Task Manager and end it there.
This occasionally occurs when I edit a test project on Core 3.0 - not using IIS, it's a class library and a test project in a solution only.
Open the Task Manager, find .NET Core Host, right-click, end task.
The dotnet watch command can track file system changes and edits and compile them in to the running process. This is done by first installing the Microsoft.DotNet.Watcher.Tools package in the tools section of the project.json file. See documentation of its usage here.
Once it is installed, you can then run the app with the command dotnet watch run and make edits while avoiding the manual restarting of the application.
I ended up recycling the Application Pool to get my dlls unlocked.
This has happened to me many times. The issue, at least in my case, has been that I have the application running. So when the compiler tries to update the dll it can't because the dll is locked and in use by the running application. Once I close the application and do the compile again, it works fine.
I may be a bit late to the party here, but for future people reading this question, it would appear that this is a bit of a 'feature' with how VS/core is able to interact with IIS and stop files from being locked:
https://developercommunity.visualstudio.com/content/problem/546858/bin-files-locked-by-iis-worker-process-1.html
It is apparently being investigated and looked into for .net core vnext.
I'm still running into this regularly in VS2017 and VS2019. Hopefully this helps someone.
This is what works every time for me.
If using IISExpress - Stop the Application using the icon in the task bar (near the clock/time)
If using IIS - Stop and Restart the site
OR
In an Admin command prompt run taskkill -F -IM node.exe (Kills all node processes currently running)
100% Working For Me
it is being used by another process .net core
go to task manager (for windows )
Right click .NET Core Host
click End Task
as like see this image
This problem offen when you set AspNetCoreHostingModel to "OutOfProcess"
then you have two solution for problem:
change hosting model to "InProcess"
use below command in CMD
taskkill /f /pid {.netcore hosting pid , show you in error line in visual studio}
For use that command, you do not use "" and {}.
For me, it worked by -
Go to your bin and the environment, take a backup for files, try deleting the folder
D:\CawProjects\EmailAnalytics\APIV1\APIV1\bin\Development
if it does not allow you to delete and says Open/Used somewhere then follow the below process.
Open task manager - find for .net core host and right-click to end the task
My company uses TFS 2010 to deploy our web apps from our local environment to our development environment. Here's the compiled output in my local directory for one of our vended web apps, ProGet, (http://inedo.com/proget/overview) in question that isn't deploying correctly. I expect all of what I see below to deploy to our development server:
Here's my .xaml build file:
Finally, here's my solution in Visual Studio:
When I queue the build, this is what's built out to our development server - notice it's missing a bunch of files/folders, but it does include "Resources" and "bin" and web.config:
This app is a vended application, ProGet, an already developed corporate Nuget repository that we purchased a source code license for. Does anyone have any ideas what I might be doing wrong?
EDIT
Here's a screenshot of my local IIS and the window to the right is a result of right clicking the website and choosing "Explore". Notice the *.cs files. Weird they don't compile down.
The Default Build Template (DefaultTemplate.xaml) should output the same files you get when you compile locally.
However, from your screenshots it looks like you are using a custom build template xxxx_DeploymentProcess.xaml that is obviously doing something different with how it outputs the build files. There is no way for us (stackoverflow community) to know what your custom build process is doing.
You could try switching back to the default template, and we'd be able to help you then. But, there's a good chance that you are using a custom build template for a reason, and you might not want to eliminate it before you know what it's doing.
We have with success been updating our development web site at a daily basis using msdeploy from TFS2010.
This was working fine until we upgraded to VS2012, our application from .NET Framework 4.0 to 4.5 and ASP.NET MVC from 3.0 to 4.0. It look like all is well and assemblies deployed but nothing has actually been deployed.
I have been looking into this for two days now and can't figure out why this is happening and now I am running out of ideas.
Below is part of my build script in the way it has been working before the upgrade.
<MSBuild
Projects="$(SolutionRoot)\My.Web\My.Web.csproj"
Properties="MvcBuildViews=False;AllowUntrustedCertificate=True;AuthType=Basic;Configuration=Dev;CreatePackageOnPublish=True;DeployIisAppPath=dev.myweb;DeployOnBuild=True;DeployTarget=MsDeployPublish;MSDeployPublishMethod=WMSvc;MsDeployServiceUrl=https://10.xxx.xxx.xxx:8172/MsDeploy.axd;UserName=UserName;Password=Password;UseMsdeployExe=True"
ContinueOnError="False"
/>
When the upgrade was initiated and my problem discovered we were using Web Deploy 2.0 but now we have upgraded to Web Deploy 3.0. I have also made sure we are building with ToolsVersion="4.0".
UPDATE --
msbuild.exe /p:AllowUntrustedCertificate=True
/p:AuthType=Basic
/p:Configuration=Dev
/p:CreatePackageOnPublish=True
/p:DeployIisAppPath=dev.myweb
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:MSDeployPublishMethod=WMSvc
/p:MsDeployServiceUrl=https://10.xxx.xxx.xxx:8172/MsDeploy.axd
/p:UserName=UserName
/p:Password=Password
/p:UseMsdeployExe=True
E:\Builds\1\WhatEver\Daily_Build\Sources\My.Web\My.Web.csproj
Now I also tried to run the above msbuild command from our TFS and no response which frustrates me completely. Nothing in the event log of TFS, nothing in log file no matter verbosity... Any ideas?
It does work using msdeploy directy like below;
<Exec Command=""C:\Program Files\IIS\Microsoft Web Deploy V3\MSDeploy.exe" -verb:sync -source:contentPath="E:\Builds\1\WhatEver\Daily_Build\Sources\My.Web\My.Web.csproj" -dest:contentPath="E:\dev.my.web",computername=https://10.xxx.xxx.xxx:8172/MsDeploy.axd,username=UserName,password=Password,authtype=Basic -allowUntrusted=True"
ContinueOnError="false" />
--
UPDATE 2 --
It appears Microsoft added a check for what type of projects that are publishable projects and our web application are not, since the Output Type is Class Library. This has been valid with v4.0 but apparently not for v4.5.
Anyone have an idea of what to do make it work again? Do I need to change the project type? Create publishing package up front and then deploy that? Or what?
--
Anyone else that has had the same problem? Have you found a solution to share?
Could there be an issue with version of MSBuild?
Here is what I would recommend. In VS2012 we have made it easy to automate publishing your web projects using the publish profiles which are created by the publish dialog. In your case create a new MSDeploy profile. When you create that profile we will save the settings into a file under Properties\PublishProfiles (or My Project\PublishProfiles for VB). The extension of this file will be .pubxml. Those files are actually MSBuild files, which you can customize if needed. You can continue to use the publish dialog as well. The password will be stored in a .user file and encrypted such that only you can decrypt it.
After you have created that profile you can publish with the command below if you are building the .sln file.
msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password>
If you are building the .csproj/.vbproj then you need to tweak this a bit in the following way
msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password> /p:VisualStudioVersion=11.0
More on why VisualStudioVersion is required at http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx.
Once you do this you will be able to build+publish just like you did previously. FYI we have shipped all these new web publish features for VS2010 in the Azure SDK https://www.windowsazure.com/en-us/develop/net/#.
Also in your question I noticed that you are specifying some custom properties, like MvcBuildViews. You can now place those properties directly inside the publish profile (the .pubxml file) if you want. Of course you can still pass them in on the command line if that makes more sense for your scenario.
More info on this at http://sedodream.com/2012/06/15/VisualStudio2010WebPublishUpdates.aspx.
If you take a look at the approach that we had for developers to automate publishing it was to specify properties and targets to be executed during the build. The problem with this approach is that this limits our ability to enhance the web publish experience. In the new release we have introduced an abstraction, the publish profile, which allows us to change the underlying targets of the web publish pipeline and your automation scripts will continue to run. Hopefully from this point forward you will not have to re-visit this issue.
I had much the same problem today. I too was trying to get a .NET 4.5 web application automatically deployed using a machine that did not have Visual Studio 2012 installed on it. There were a couple of minor differences in my situation, however: I was using TeamCity instead of TFS, and our solution was created with .NET 4.5 as opposed to being one that had been upgraded from .NET 4.0.
Nonetheless, I did have the same problem described. I'd use MSBuild to build the web app and deploy it to IIS, in much the same way. This approach worked fine on my dev machine. However, when I ran MSBuild on the CI server, it quite happily built the web app, but it stopped after that: no errors, no warnings, nothing, just a message that the build was successful. There wasn't the slightest hint of an attempt at deploying the app to IIS.
It seems MSBuild was missing the relevant targets to perform the web deployment.
The fix was to copy the folder C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web from my dev machine to the CI server, copying it to the same place on the CI server as it was on my machine.
Once I did that, MSBuild then grumbled about needing Web Deploy 3.0, but that was fixed easily enough. After installing that on the CI server too, MSBuild quite happily deployed the web app.
To extend Luke Woodward's answer:
I, too, found that deploying C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\ from my local machine to the build server was the fix.
However, the real fix is to install the Microsoft Web Developer Tools as part of the VS 2012 installation, which will create this folder, among other things. This addresses Ieppie's licensing objection.
I tested this by...
Deleting C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\
Running the VS 2012 installer and adding MS Web Dev tools.
Verifying that, after the install, C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\ was back.
I seem to have missed Day 1 of MsBuild 101. I find myself asking "What does it do, what does it replace, and when do I need it?" since I can just hit F5 and compile my application.
What is the bigger picture I'm missing?
MSBuild is the build platform that enables all build activity in the Visual Studio world.
A better, more practical example would be to state that
The .csproj files (every C# project) are msbuild files
When you hit F5, you basically (oversimplifying) call msbuild.exe and passing in your .csproj file.
MSBuild empowers all the things that make hitting F5 work. From creating the "debug" or "release" folder, to dropping references into the bin\ directory, to invoking CSC ... and everything in between ... MSBuild "powers" all that.
If all you will ever need from a build is the output that F5 gives you, then you know about all you probably need to know about MSBuild.
In most commercial/practical development scenarios, however, there will come a time where there is a need to customize the build process. The most common approach is automating the build process (using either TeamBuild or some homegrown system). You may also need to
create a "packaged" deployment
link to another library outside of your project that is also actively
being developed
publish your build to an FTP and send an email to a customer notifying
them of its availability.
The use of a unified and extensible build platform (ie MSBuild) is what makes all these these possible, while still being part of the build process ... keeping the "build" part of the development pipeline simple and contained.
It's useful when you want do automated builds, and have to implement a build process
The F5 Key Is Not a Build Process and links therein (e.g this) is a good read in that regard.
Also, your Visual Studio project files are msbuild files. If you want to do more advanced stuff when you build (e.g. run a javascript minifier, have more control over autogenerated version identifiers, post processing of files etc.) , you'll have to dig into msbuild.
msbuild is used when you want to build your project from the command line. Whenever you see a continuous integration product that will automatically build your project, it will call msbuild to perform the actual build step.
I think that build servers should have the option to press F5 key in a simpler way than via windows API.
I know this is pretty stale, but here's my take on MSBuild.
It's a scriptable build tool really similar to ANT. They both use XML for configuration, so you'll be able to figure it out fairly quickly. Both have the concept of "Targets" for instance, lots more similarities in thinking, if you know ANT the switch shouldn't be tough.
MSBuild files generated from Visual Studio is really like the generated ANT scripts you get from Eclipse that build your projects, remember your includes and define your dependencies. You can modify them directly for fun and profit.
I like MSBuild, it fixes some of the stuff I find annoying about ANT.