I have recently added a new user onto my domain and swapped over to use that continue developing a project using git.
I've just re-run the unit tests and chutzpah is looking in the old source directory for js file:
"C:\Users\Liam-Laptop\Source\Repos\InvestorsEdgeWeb\AtlasWeb\Scripts\Atlas\Objects"
whereas it should be looking at:
C:\Users\Liam\Source\Repos\InvestorsEdgeWeb\AtlasWeb\Scripts\Atlas\Objects
I don't seem to have a chutzpah.json file so where is it getting it's settings from and how do I change it?
Related
I am trying to deploy an web application that was created on VB with the .NET Framework 2.0 using the TFS 2017 continuous deploy. It doesn’t have a solution file inside like vbproj or csproj, so I needed to avoid all the suggestions to include extra information on the vbproj.In order to run the MSBuild even locally I need to change in my .sln this tag, so all my compiled code is also there
Debug.AspNetCompiler.TargetPath = "....\PrecompiledWeb\ARB\Debug\"
Unfortunately, I can’t deploy the application using the TFS. So far I tried to deploy it through my Visual Studio project, and is working fine with every option: I tried MSDeploy, Web Deploy Package, and FileSystem, and is working fine from the Visual Studio Publish Option
With that, even my transformation take place.
Now lets say I go to my TFS and I put this parameters on the MSBuild
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsASingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="\\MyServer\Content"
My files are compiled but never stored in my Content folder. No one of them!!! I can’t figure out what is going on here.
From your screenshot, you are using a Web Site project, not a Web Application project. The output structure of a Web Site project in TFS is different from build in VS (you can see a PrecompiledWeb folder in your build source directory on build agent server). Instead of using MSBuild argument, you can consider add tasks below to copy the files you want to publish:
We strongly suggest you switch from Web Site projects to Web Application projects to avoid these issues.
I’m having a "build partially succeeded" issue with this error “NUnit failed to load e:\Builds\184\CSTax\706USServices_Test\bin\Calc.Tests.dll”, but all of the unit test in this project ran and passed (all green).
Build environment
1) Using NUnit 2.6.4 and NUnit Test Adapter 2.0.0
2) TFS 2013 – upgraded from 2012
3) Visual studio 2012 and 2013 have been installed on the server
4) I did install the NUnit Test Adapter, using the Extensions and Updates in 2013 Visual Studio
5) Using build process templates from TFS 2012, even if I switch to the 2013 default build process templates I get the same error
6) I tried changing the project to copy the nunit references locally (including the test adapter), they did make it to the bin folder, but still fails
7) I used process monitor to see if I could find the failure, everything looked good, the dlls were copied from the packages folder to the bin folder and loaded.
I’m sure it has to be something in our build environment, but I do not know where to look, I need my builds to go green. Any ideas?
The issue is a bug in the NUnit 3.0 test adapter, I removed our E2E project off of the build server and all my builds went green. NUnit is looking into this bug.
You need to:
Download the NUnit test adapter: https://visualstudiogallery.msdn.microsoft.com/6ab922d0-21c0-4f06-ab5f-4ecd1fe7175d . Rename the NUnitVisualStudioTestAdapter-2.0.0.vsix to NUnitVisualStudioTestAdapter-2.0.0.zip. Unzip NUnitVisualStudioTestAdapter-2.0.0.zip.
Check in the following dlls: nunit.core.dll, nunit.core.interfaces.dll, nunit.util.dll and NUnit.VisualStudio.TestAdapter.dll into a folder in TFS Version Control.
Specify the build controller's path to custom assemblies:
Then queue a build, the NUnit test methods will be run.
Also have a check on the Enable a third-party unit framework part of this MSDN article for the details: https://msdn.microsoft.com/en-us/library/vstudio/ms253138.aspx
We have just upgraded a build server to TFS 2013, and Visual Studio 2013, and are running into problems. We have a MSBuild (.proj) file that triggers the generation of a solution (.sln) file using CMake, and then a sub-MSBuild step that builds this solution. The CMake part finishes without issues, but when MSBuild tries to build it, we get the following error from all the projects in the solution:
Error MSB4025: The project file could not be loaded. Could not find file (project file name).metaproj
The metaproj files are not present next to the projects, but as I understand it, these files are never stored to disk but kept in memory instead. The exact same sources still build fine on our 2012 build server, as well as locally using Visual Studio 2013. The only changes we have done are to generate 2013 solutions, and set the ToolVersion to 12.0 for the "bootstrap" MSbuild file.
I was using the old DefaultTemplate.11.1.xaml build process template for building the project on the build server. I gave up on trying to make it work with that template, and converted to the new TfVcTemplate.12.xaml instead, and that solved the issue.
I still don't know what caused the original issue, but determined that it was not caused by CMake, as it could be replicated without CMake in the equation.
I have a WebAPI project in Visual Studio 2013. If I build the project in Visual Studio, in the bin/ directory I see a file called MyProject.dll.config, which represents the web.config file at build time.
However, if I execute MSBuild from the command line, the .config file is missing, but all other files are present.
> msbuild.exe /t:build /v:q /p:Configuration=Debug /nologo \
D:\Workspace\MyProject\src\MyProject.sln
What gives? Why isn't the .config copied?
For deploying a web project or a web api project, the fact that there's no $(TargetName)$(TargetExt).config isn't a big deal. At run-time, IIS will use Web.config to figure out everything it needs for your assembly.
BUT!
If you're using a Web App or Web Api project as the basis for testing* then you can hit some snags. In particular, when it comes to assembly binding redirects (as is the case with something within the bowels of MVC which still relies on Newtonsoft.Json 4.5.0 when the current version at time of writing is 7.0.0). A colleague had a similar issue with another assembly his test project was depending on.
Now when you run your tests through Visual Studio (eg, via Resharper), they all work just fine. However, when your tests get to the CI server and they are run by nunit-console, you'll see assembly load errors. Not pretty. This is because of the described behaviour where VS is sneakily copying the .config file to the correct output and msbuild isn't. However, you can work around this with a post-build build event:
copy $(ProjectDir)Web.Config $(TargetDir)$(TargetName)$(TargetExt).config
This has resolved my issues with redirects. I hope it helps someone else.
You may ask "Why use a Web App or Web API project as your test project?". A Web* project is a lot more comfortable to deal with as a base for a test project which deals with .net assemblies and JavaScript tests as JavaScript is properly recognised (syntax highlighting) and there's a Scripts folder which has the quick "Add -> Javascript File" menu item for itself and descendant folders, so I prefer to use this instead of a plain Class Library project.
When I create a WebAPI project the web.config Copy to Output Directory is set to Do Not Copy by default. Did you select the Web.config in Solution Explorer and set this to a copy action?
I'm at a loss to explain why it seems to copy for you with the IDE build but NOT the msbuild cmd you show, this is not the behavior I see with a fresh WebAPI project in 2013.
Whenever I publish my MVC web application in VS 2010 via the One-click publish feature (I'm not doing any web.config transforms or anything fancy - yet!). The next time I come to build the app I get the following error:
It is an error to use a section registered as allowDefinition='MachineToApplication'
beyond application level. This error can be caused by a virtual directory not being
configured as an application in IIS. in ...MyWebApp\obj\release\package\packagetmp
\web.config
A new copy of the web.config file is indeed created by VS2010 below the ...MyWebApp\obj\ folder so I deleted the whole obj folder and I was then able to build again.
But I shouldn't have to do that each time I publish - I must have something configured incorrectly - can anyone help please.
Thanks.
This is unfortunately a known issue with Publishing a web application to the file system. This still affects the release version (RTM) of Visual Studio 2010. It's not limited to the Beta or RC versions.
This problem "bit" me also, and I too was having to manually delete the Debug and Release folders inside the obj folder within my web site solution folder.
The real answer for an automated "workaround" can be found in this answer to the other Stack Overflow question:
Why do I randomly get a “error to use section registered as allowDefinition='MachineToApplication'” when building an MVC project?
In a nutshell, you need to delete the web.config files from either the Debug or Release folders (or both!), and that's achieved with a pre-build command (configured in the Build Events tab of the Project Properties page of your solution):
del "$(ProjectDir)\obj\Debug\Package\PackageTmp\web.config"
del "$(ProjectDir)\obj\Release\Package\PackageTmp\web.config"
Personally, I delete the entire obj folder since all those files are re-created with each build anyway.
I have just found a work around for this that has worked for me, open the .csproj for your web project and change the node under the Project\PropertyGroup node to this:
from this:
<MvcBuildViews>true</MvcBuildViews>
to this:
<MvcBuildViews>false</MvcBuildViews>
This has worked for me, hopefully it will work for you also.