I'm using tfs 2015.3 and I'm trying to compile a web service project (.asmx).
Now, my build failed because of this error: It is an error to user asection registered as allowDefinition='MachineToApplication' beyond application level
I looked online for solutions and found that there is a problem at the build when 2 web.config is at the same project (one at the root and one is somewhere at the project's folders). Then I saw that a folder named PrecompileWeb was created with content of another project from the solution.
I tried to build the project at vs2013/2015 and the folder does not get created, as opposed to with msbuild (which tfs probably uses).
How can I prevent this folder from appearing? I saw a solution that suggested giving a property of '/p:PreBuildEvent=' or something like that, but it's not working.
Related
Using Visual Studio 2019 to build a .Net Core website and publish to Azure was working fine up until I just deleted a DataContext file and an Entity class through Visual Studio. I can build and bring the site up locally without any issue but when I try to publish the site to Azure I get an error that the two files I deleted could not be found. I've checked in my code along with the solution file. The message is correct, those files are no longer available but I'm not understanding why it's looking for them since I deleted them through VS and the solution/project file should have been updated. I've done some searching but can't find anything that specifically address this. I guess I could roll back to right before I deleted the files but then I'l have to update some code. Anyone know if I can look somewhere that is referencing these files for publishing so I can delete the reference? I've searched the whole solution for the name of the files hoping I could find a reference but it isn't finding anything.
I refactored my MVC/Entity Framework projects by separating namespaces into separate projects. So I now have this structure:
MySolution.Data
MySolution.Data.Contracts
MySolution.Model
MySolution.Website
Everything builds and runs in my development environment. However I hit problems when I tried to deploy to my "Staging" server.
The problem I have is that it would not build when I changed the solution configuration to "Staging". In the configuration manager all the projects also have "Staging" configurations. I assume these were created when the new projects were added.
The first thing I tried was to create a new solution configuration with everything copied from Debug named "Solution 2". No luck, still fails.
Then I figured that I only need a different configuration for the Website project - where I transform the configuration file. So I changed the solution configuration, telling it to build and deploy the "Debug" configuration of Hub.Model - which from the first error message looked like the problem project. Sure enough it now builds.
The first error message (of 263) is:
The type or namespace name 'Schema' does not exist in the namespace 'System.ComponentModel.DataAnnotations' (are you missing an assembly reference?) MySolution.Model
So it looks like a problem with references to Entity Framework dlls
While I do have a workaround for now, I am concerned that this unexplained error will come back and bite me at some point in the future - probably just when I am about to deploy an urgent fix.
So why would one of my projects fail to build when I change project configuration?
You need to make sure you are installing proper nuget packages and referencing all assemblies.
The solution of the error you have shown is as below: (Reference)
You have to reference the assembly in which this namespace is defined
(it is not referenced by default in the visual studio templates). Open
your reference manager and add a reference to the
System.ComponentModel.DataAnnotations assembly (Solution explorer ->
Add reference -> Select .Net tab -> select
System.ComponentModel.DataAnnotations from the list). Then select that reference and under properties set "copy local" to true and once you publish it will be in your bin folder and wont impact at all on any server be it x32 or x64.
Happy coding :)
We have a very large solution (some 300+) projects and we are trying to build it via MSBuild on TFS2010.
We can build it via MSBuild on all out development machines, and are in the process of adopting TFS.
The structure of our code is like so:
bin\Client
bin\Server
Framework\ClientFramework.csproj
Modules\Module1\Project1
Modules\Module2\Project2
etc.
Each project has a relative OutputPath which builds the code to the bin Client or Server directory. So for example, Project1.csproj has an OutputPath of "..\..\bin\Client".
We seem to be having a problem that in TFS MSBuild the OutDir is set to a Fixed Path:
C:\Builds\MyProject\Binaries\
So things are getting confusing when resolving the relative OutputPath on top of the OutDir
ClientFramework goes to C:\Builds\MyProject\Binaries\..\bin\Client
Project1 goes to C:\Builds\MyProject\Binaries\..\..\bin\Client
etc.
We also have some Post build events that copy some 3rd Party dll's to the bin folders, these paths cannot be resolved properly either.
I think the solution we are after is to build everything to our existing bin\Client, bin\Server structure and then move the Folders from bin to Binaries.
Any ideas on how to accomplish this or how we should be working, are appreciated, but updating our existing projects might prove problematic, as it all works with VS, developer command line builds and with CC.net.
Since this is first link that pops up with a Google search of "TFS OutDir", I must provide a newer solution. I spent an entire day playing around with OutDir, OutputPath, and overriding them with TeamBuildOutDir. A better solution is to set the MSBuild property GenerateProjectSpecificOutputFolder. It comes with .NET 4.5. More info here: http://blog.codeassassin.com/2012/05/10/override-the-tfs-team-build-outdir-property-net-4-5/
I found the answer on MSDN : http://msdn.microsoft.com/en-us/library/ff977206.aspx
We have installers referencing a wixlib file to get some common functionality. The wixlib is built in another solution then moved to a folder within that solution. When we try to build the installers with a TFS build, we get an error from light.exe:
light.exe: The system cannot find the file '..\..\..\Core\Common\assemblies\v1.0\Common.Wix.wixlib' with type 'Source'.
Our regular projects can reference \assembiles\v1.0, since we have some other common assemblies stored there. How do we get WiX to recognize this location during build?
You are referencing wixlib directly. So as far as I understand the TFS build process, it should be added to TFS project of your solution. TFS project shouldn't be dependent on the output of another non-dependent solution. It is at least bad practice. And in any case you can't guarantee this output would be generated before your project build on server.
As far as I remember, TFS build creates separate folder for each build and gets sources there. So your solutions are no longer on the same folder hierarchy level.
One more point in favor of explicitly copying wixlibs into your installer project: versioning - in this case any bugs made in the common library will not immediately break all projects that reference it. And you can gradually upgrade and test every project. Can you imagine auomatically downloading new version of any 3rd party dll on every build? Any change in that dll will immediately break your application even if changes are not critical to you.
Since the shared component and the active solution are in two separate projects in TFS, the workspace must be setup so that the relative paths for references remain intact. The easiest way to do this is to set your Build Agent Folder structure in Workspace in your TFS Build to have $(SourceDir) represent your root. However, don't change your Source Control Folder - that stays the same.
For example, say you have the following structure:
-TFS
|-SharedComponents
||-MyComponents
|-ProjectArea
||-MyProject
You would want to have the following two items in the build Workspace:
Source Control Folder Build Agent Folder
---------------------------------------------------------------------------------
$/ProjectArea/MyProject $(SourceDir)\ProjectArea\MyProject
$/SharedComponents/MyComponents $(SourceDir)\SharedComponents\MyComponents
This mimics the structure in TFS in your build folder, thus allowing all relative paths to remain intact.
One more note about this configuration: Since you have the shared components in another location, you may want to create a solution folder in MyProject and add the components that you are using to it. This will ensure they get pulled automatically when anyone loads your project from TFS - they won't have to go back and pull down the share components folder separately after discovering a build error.
I have my custom continous build that log an error for my tfs service host.
Service 'Default Agent - basv-tfs-001' had an exception: Exception
Message: Problem with loading custom assemblies: API restriction: The
assembly
'file:///C:\Windows\ServiceProfiles\NetworkService\AppData\Local\ProjectBranchDevelopment\BuildAgent\2\ReportViewer.ProcessingObjectModel\Microsoft.ReportViewer.ProcessingObjectModel.dll'
has already loaded from a different location. It cannot be loaded from
a new location within the same appdomain. (type Exception)
I have found i have the same dll saved in 2 locations in my repository.
can i hide it from build?
Edit the workspace in your build definition. Add a reference to the folder containing one of the dll's and change "active" to "cloaked" that will stop TFS getting that folder during the build
I've seen this in tests where it's defaulted to using **test.dll (or similar), to get round this I changed it to just test.dll, since it was (as the error suggests) finding it in multiple locations.
So whatever is attempting to resolve your DLL is probably doing something similar. Not a solution I know by may help you track down the offending code :)