I've seen msbuild commands pass /t:pipelinePreDeployCopyAllFilesToOneFolder as a target. On searching the Internet, I've found many forum and question/answers posts about this target. That said, I've found no official documentation.
What does this target do?
Where does Microsoft document it?
This target usually goes along with a _PackageTempDir property.
My best guess is that the target and property together mean that, before deployment, copy all files to the specified package temp directory.
Seems like it's a Web Application specific default target.
As mentioned in this answer it is in the following file:
It's actually contained in the file that Sayed Ibrahim Hashimi mentions, which is the Microsoft.Web.Publishing.targets file (C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets).
You can check what its content here. (I found a copy on github)
Neither I could find the mentioned target among any documentation. However, there is a documentation of msbuild on github with some fancy figures. Also, there are other documentation fragments on Microsoft's documentation about Default build targets or Common target files.
Since pulling changes, building my InstallerBootstrapper project in Visual C# 2010 fails with:
Could not find a part of the path "WiX Toolset v3.8\bin\IA64\burn.exe"
Indeed this directory does not exist, but it never did and the InstallerBootstrapper was building correctly before pulling.
The .wixproj and .wxs have not changed.
I reviewed the changes but can't seem to find what change could have caused that.
No file in the whole solution contain the string "IA64".
I have not updated WiX since a few months.
Google does return anything with these words.
Any idea what could have happened?
For some unfathomable reason, InstallerBootstrapper was configured to use IA64:
This happened when I re-imported the Installer et InstallerBootstrapper projects into the solution. No idea why, but it can be fixed by editing the solution file or using the COnfiguration Manager.
I should have searched for the lowercase string too.
in our WiX 3.8 project (creating an MSI) , we'd like to have new languages like es-es, fr-fr, ru-ru, etc.
After adding the files and building I get the following error multiple times saying that the variable is not defined:
"1>C:\src\wix38\src\ext\UtilExtension\wixlib\UtilExtension.wxs(54,0): error LGHT0102: The localization variable !(loc.msierrXmlFileFailedRead) is unknown. Please ensure the variable is defined."
Same error for those variables also: !(loc.msierrXmlFileFailedOpen), !(loc.msierrXmlFileFailedSelect), !(loc.msierrXmlFileFailedSave), !(loc.msierrSecureObjectsFailedCreateSD), !(loc.msierrSecureObjectsFailedSet), !(loc.msierrSecureObjectsUnknownType)
So I created a modified version of WiX. I downloaded the sources and added the corresponding language files (fr-fr.wxl, es-es.wxl, etc) into that folder: \src\ext\UtilExtension\wixlib
I also changed \src\ext\UtilExtension\wixlib\UtilExtension.wixproj so that it includes those files.
Then I built everything successfully, copied the new files into wix installation directory, restarted visual studio and built again - with exactly the same error.
What did I do wrong?!
Btw: I found a workaround by referencing the new language files (fr-fr.wxl etc) in the wixproj file, but I don't see this as a final solution.
Any help is appreciated!
As a solution can be downloaded en-us.wxl language file and modify it any references to your language indicated cultures.
Repository with extension WXL files: https://github.com/wixtoolset/wix3/tree/develop/src/ext/UtilExtension/wixlib
In light pass control these parameters with the path of your file with translation strings: light -ext WixUIExtension -ext WixUtilExtension -ext WixFirewallExtension -cultures:pt-br -loc D:\pt-br.wxl ...
I had/have the same problem, some googling turned up that the extensions aren't all translated yet.
I faced the same problem, and maybe my solution will be userfull to somebody.
There is no localization to this variables (msierrXmlFileFailedSelect etc) in fr-fr and es-es cultures, that's the key. You need to find files UtilExtension_fr-fr.wxl and UtilExtension_es-es.wxl and include them to your project OR copy the localization of this variables from this .wxl files to localization files in your project.
I've just been assigned a task of working (learning) WIX. To better understand the dialog handling and stuff, I found many references of "just get..." and then WixUI_InstallDir.wxs and InstallDirDlg.wxs (and obviously the others out there).
I've searched all over (several hours) and have YET to actually find the raw .WXS files these other links have directed me to.
Thanks for the help...
In case you are looking where wxs files are in the source tree, for 3.6 they are here:
src/ext/UIExtension/wixlib
And as AntonyW already pointed out the source can be downloaded from codeplex. This is the link for version 3.6:
http://wix.codeplex.com/SourceControl/list/changesets?branch=wix36
The lastest version is available through this direct link:
http://wix.codeplex.com/SourceControl/latest#src/ext/UIExtension/wixlib/InstallDirDlg.wxs
For version 3.5, the source code is at http://wix.codeplex.com/SourceControl/list/changesets?branch=wix35
The files can be found in the folder where Wix Toolset is installed.
C:\Program Files (x86)\WiX Toolset v3.11\SDK\wixui
And here's the latest source files. Thanks for the help.
http://wixtoolset.org/releases/v3.7.1015.0/wix37-sources.zip
We have a ASP.NET MVC with 4-5 different build configurations. Whenever we change the build configuration, we need to delete the obj folder for the web project, since we get the 'allowDefinition='MachineToApplication' error. A pain, but we managed by deleting the folder in pre/post build events.
Now I need to configure our CI to build deployment packages. This means that I cannot delete the obj folder. Every time I compile e.g. with the following msbuild parameters
/p:CreatePackageOnPublish=true /p:DeployOnBuild=true
I recieve the error:
web.config(123): error ASPCONFIG: 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.
As far as I understand, the problem is that there's multiple .config files in the project - In our case, there's not. I could really use some help to find an explanation and find a permanent (no- hack) fix.
Edit:
This question is marked as a duplicate, but the corresponding answers and cause(s) in the 2 threads, are clearly different from each other. Not sure what is intended with this tag - I've read that particular post before posting this question, as it didn't answer my question. There's multiple causes for this error message. It is 'similar', but definitely not a duplicate!
There is a similar question here on SO with some good solutions for this issue.
The problem is that building a deployment package creates a copy of the web.config in a subfolder of /obj. That will normally be be cleared out if you do a rebuild or a clean. However, if you build a deployment package in one configuration (e.g. Debug) and then switch to another confguration (e.g. Release) the obj/Debug folder is not cleared out and the web.config file there causes problems.
The quick solution is to clean all configurations and then do a (re)build. Alternatively you could delete the /obj folder in your project.
To permanently resolve the issue you can either move the intermediate output (/obj) out of your project folder or modify the project to force a clean of all configurations on rebuild.
I too was deleting the obj folder until I had a conflict with a build script which required it. Catch-22, I used the accepted answer on the following SO link to move the location of the Obj folder to C:\Temp\BUILD. You have to do it per csproj file, but it is a great solution.
Here is the link: VisualStudio: How to save the obj folder somewhere else
Note that I am using a variable for the project name.
R:\Temp\Build\Debug\$(MSBuildProjectName)
I have the above line in both debug and release sections for all my projects, including class projects. My build path is a ram drive for speed. See this SO for more info: How to access macro variables within csproj file?
I just answered a similar question here. To recap, I ran into this problem in one of our MVC projects, and it was due to having the MvcBuildViews property in the project file set to true. Setting the property to false fixed the problem.
<MvcBuildViews>false</MvcBuildViews>
I also found this answer which outlines an alternative that does not require turning off view building.
I don't know that there is an "official" fix as it just seemed to start on multiple projects of mine for no reason that I can find in Visual Studio Premium 2012 (never happened in previous versions of VS).
As a work around to automate the deletion of the obj directory as others have said, similar to an answer by user Casual in this post VisualStudio: How to save the obj folder somewhere else, where unfortunately just moving the location of the obj folder didn't always seem to work.
Instead I added a few commands under Build Events in the Pre-build event command line:
rd "$(ProjectDir)obj" /S /Q
md "$(ProjectDir)obj"
md "$(ProjectDir)obj\Debug"
md "$(ProjectDir)obj\Release"
You can change/add/remove subfolders to match your custom build configurations using the line where buildConfigName matches the name of the build configuration you are using:
md "$(ProjectDir)obj\buildConfigName"
Hope this helps!
That error indicates that you are trying to something specific to an application at an IIS tree level that isn't defined as an application. For example if you try to do app-level functions in a web.config in a virtual directory, you will get that error. You need to find the path you are deploying to and make sure that it is defined in IIS as an application vs a folder or vdir.
Cleaning the solution (Right click Solution in VS, clean), worked for me.
I had the same error but with a deployed page.. Then realized my webserver's clock was set back to 2010 for some reason. set it to the correct date fix my problem
Clean your project
Remove the /obj folder (probably using publish and deploy? - there is a bug in it)
Althoug the problem is explained and solved in one way in the accepted answer, I wanted to show a solution which can be better for other cases. This solution has been included in some version of VS, but I can only say that I had the problem in VS 2013 Update 5. (See the "Beware" below, it could be fixed in this version, but not working only in my particular case).
I borrowed the soltuion from Error: allowDefinition='MachineToApplication' beyond application level on Visual Studio Connect.
The solution consist in including these lines to the web application project (.csproj file) which handle the deletion of the offedning intermediate files (which wans't a solution for the accepted answer, as he needed those intermediate files):
<!--Deal with http://connect.microsoft.com/VisualStudio/feedback/details/779737/error-allowdefinition-machinetoapplication-beyond-application-level,
we will need to clean up our temp folder before MVC project starts the pre-compile-->
<PropertyGroup>
<_EnableCleanOnBuildForMvcViews Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='' ">true</_EnableCleanOnBuildForMvcViews>
</PropertyGroup>
<Target Name="CleanupForBuildMvcViews" Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='true' and '$(MVCBuildViews)'=='true' " BeforeTargets="MvcBuildViews">
<ItemGroup>
<_PublishTempFolderNamesToCleanup Include="Database;TransformWebConfig;CSAutoParameterize;InsertAdditionalCS;ProfileTransformWebConfig;Package;AspnetCompileMerge" />
</ItemGroup>
<!--Force msbuild to expand all the wildcard characters so to get real file paths-->
<CreateItem Include="#(_PublishTempFolderNamesToCleanup->'$(BaseIntermediateOutputPath)**\%(identity)\**\*')">
<Output TaskParameter="Include" ItemName="_EvaluatedPublishTempFolderNamesToCleanup" />
</CreateItem>
<Delete Files="#(_EvaluatedPublishTempFolderNamesToCleanup)" />
</Target>
Beware: for some reason, probably because I included it myself in the project, my build target for building the views was named "BuildViews", instead of "MvcBuildViews", so I had to modify the BeforeTargets attribute accordingly.
This is not necessarily the exact same issue, and to be honest, probably down to pure lack of knowledge on my part, however I had this same error when:
I set up a standard asp.net new project actually just used for HTML5 stuff so nothing other than the usual project structure
I then (not thinking perhaps!) added a new WCF REST project (which actually was just another base asp.net project using very good examples from http://www.codeproject.com/Articles/128478/Consuming-WCF-REST-Services-Using-jQuery-AJAX-Call?fid=1597004&df=90&mpp=25&noise=3&prof=False&sort=Position&view=Quick&fr=26#xx0xx and http://geekswithblogs.net/michelotti/archive/2010/08/21/restful-wcf-services-with-no-svc-file-and-no-config.aspx
The problem was I added the WCF REST project (#2) as a SUB-DIRECTORY of the main project (#1) and then tried to build! even if I cleaned the project of course.. I also made both projects use IISexpress because I thought there was an issue using the same port or something.
Of course the build process saw the web.config from #1 and then a sub-dir with another web.config #2..
I realise this probably should be a very basic understood gotcha and it has caught me out a while ago, however sometimes it's the simplest of mistakes that are a real pain!
Might help others... who perhaps haven't had their morning coffee..
tip 1: clean & then rebuild.
tip 2: just close VS and open again.
tip 3: the downloaded project may be inside another sub folder... open the folder which has you .net files.
c:/demo1/demo/ (all files)
You should have to open demo from vs... not demo1.
I have a somewhat a similar problem, i had the main config as Copy Always so it copied the config to the bin directory. When i republished the main project, i got the MachineToApplication error. So my solution was to just change the config to Do Not Copy and remove the extra configuration in the bin folder.