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.
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 have a solution file created with Visual Studio 2013. In it, I have a WCF project which contains some classes, and a Web Application project that calls some functions from WCF file. The web Application is able to reach it from codebehind of .aspx pages.
I have no issue building and compiling the WCF project. However, Visual Studio is unable to identify their classes.
In Web Application project, It underlines the using statement of the WCF class library in red, shows "Type or namespace could not be found" error. It takes the class from the file created by WCF automatically by Visual Studio.
WCF project is doing the same inside too. The two classes are in the same namespace, in fact, literally in same file together. Yet they can't see each other.
Long story short: I have 2 different projects in the same solution, they work and compile very well, but Visual Studio is unable to identify some of the classes in intellisense, even suggests to create new class. What would cause this?
EDIT: I removed the project from TFS, and the classes are colored properly, and so is the intellisense. Perhaps some files are locked as checked in, and causes trouble?
Usually we do not suggest adding the BIN and the OBJ folders to source control, but do add the 3rd party dll's or using nuget package to handle them. Basically all that you need as input for your application is in source control, but the output of you application (the created dll's, pdb's etc) should not be included.
If you insist on this, first please double check you have add all related dlls in source control(check in them).
Then if your local build is successful and just the TFS build is failing
then it is usually due to dll reference path issue. Make sure that the
Dll is referenced as a relative path in the project file (.csproj).
Also give a try with adding the dll files into the bin folder where the builds located in TFS server. That .dll needs to be on whatever machine(build server) is running the build and the build definition needs to be pointing at that location.
Please take a look at this similar question: Namespace could not be found - building using TFS
I unticked readonly option from my .sln file.
I opened my .sln file with notepad and removed all the "GlobalSection" properties. (Related with TFS)
This solved the problem.
We have some assemblies that are not referenced by our solution directly but are required for other libraries we are using.
I noticed in VS 2010 you can add a deployable assemblies folder and that would cause the files in it to get copied to the bin while building, it seems this was removed in 2012 as all of the Microsoft stuff is available in nuget now.
What is the best way to achieve this same effect, can I just add a folder to my project and add an after build copy task to copy all of that into the bin or is there a better way to go about this.
Currently the dlls are sitting in the project root and have their build action set to content which I gather makes them get copied to the bin, however I'd like to make it a bit simpler and not have to rely on having to set things as content.
What you're doing already isn't a terrible way of handling things, to be honest, and the way we've always done so here in my day job is simply to add the assemblies into our solution as references; that does mean that they pollute Intellisense, however.
Alternatively, Phil Haack blogged that you can create a folder called _bin_deployableAssemblies and put your files in there; Visual Studio 2010 will automagically copy those into your bin folder as a part of its default build action.
This doesn't work with TFS msbuild scripts, apparently, so The Dev Stop guys blogged about how to get that to work with TFS, using a customised Target in your msbuild script.
If _bin_deployableAssemblies is no longer working in Visual Studio 2012, I would guess you could add a build action to your project file, based on the TFS build action from The Dev Stop?
I have an issue. We are upgrading to VS 2012 at work. When we open a VS 2010 project Visual Studio converts the project. This is fine, because VS 2010 can still use the project (yay microsoft). However, there is a \Backup folder created in the solution directory. Is this being created as part of the migration? Is there any way to control it?
The reason I ask is that the process that makes this folder copies web.config files into the folder. If you then try to build the solution (these are MVC projects), we get a "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." error. The cause is that there is a web.config file in a subfolder instead of the root folder. We did not make and do not want this change, and cannot figure out how to control it. Deleting the Backup\Web.config file fixes the error. Renaming it from web.config to web.config.bak fixes the problem.
I don't really want to have to personally open and convert every single project, and don't want random people bumping into this problem. Any idea how to either stop VS from creating the Backup folder, or how to make it create them in the my documents studio folder etc? I can't find any setting to control this and can't find any good info.
By chance, are you using the MvcBuildViews property to pre-compile your views at build time? If so, this is why you're encountering this (since it does the pre-compile in the same directory, it doesn't filter out any of the files below the project directory).
Note that you will also encounter this issue if you use the Publish feature for this project. Publish copies the web.config under your intermediate build output directory (by default, obj/) before and after applying web.config transforms.
The good news is that in VS2012, or in VS2010 with the latest Azure SDK installed, pre-compile is now supported for Web Application Projects (including MVC). These settings are currently in the project properties, under the Package/Publish Web tab.
(this doesn't directly address your question about the Backup folder, but it was too long for a comment.)
There is no way to control it that I found. We had to go ahead and run through and convert every project to 2012 and delete the backup folders to prevent any other team from running into it.
I'm making a build using FinalBuilder Pro 7.
I've an ASP.NET web site and I'm trying to use FinalBuilder's "Precompile Asp.net 2.0 Application" action. Well, It fails.
To build it successfully I need to run Visual Studio, open the web site and either build it manually from within VS or manually update all references. After that it works.
Now the question: How to force FinalBuilder to update those references? Even if I create web deployment project associated with the web site and try to build it with msbuild action it would fail for the same reason. Somehow neither action updates references automatically.
Update: OK. Maybe I need to force msbuild to update references. How to do that?
I found some properties that I can change at msbuild action.
On called ResolveAssemblyReferencesDependsOn I tried to put the value = true. Didn't help.
Any ideas?
There are different types of projects in .NET like library project, website project, web API project etc. As you mentioned in your question it is a website project, so I am going to give you a solution for website project.
You can build a project by two ways. Either you can build by visual studio or you can build by using MS Build. If you build your project by using VS, you can update references of your dependencies by executing the command "Update-Package -reinstall" in package manager console. It will reinstall all the packages automatically.
Please note that, all your dependencies are listed in packages.config file.
Secondly if you have to build your project by MS Build using cmd prompt, to load all the dependencies from nuget, you have to execute nuget.exe. By which all your dependencies will be loaded, but their references may not be updated. So in website project you do not have .proj file. So you can't have access to the references of your dependencies. Now problem is that how you can modify your dependencies references?
In website project reference of an assembly exists in its .refresh file. So you have to modify that .refresh file to update the reference of an assembly in website project.
Have you tried using the 'Build VS.NET Solution' or 'MSBuild Project' actions? Both should resolve your assembly references, provided the reference is set to the right location. This requires that you at least have a project file.
As I understand it, the Precompile action (which uses the MS aspnet_compile.exe - see http://msdn.microsoft.com/en-us/library/ms229863(VS.80).aspx) is designed to re-compile an asp.net application which has previously been built via VS or MSBuild. It does either an in-place compile to improve performance for the first user that hits the site, or creates a deployable application (removing source code etc). It's not meant as an alternative to VS/MSBuild.
I'm not 100% sure I understand the problem, but I believe you need to be able to correct some pathing on an assembly reference automatically.
I created a project to handle this (along with some other things): refswap.codeplex.com