I can run my Asp.Net MVC 2 application without an issue on my local computer. Just Run / Debug.
But if I have already built it, I can't publish it! I have to clean the solution and publish it again. I know this is not system critical, but it's really annoying. "One Click Publish" is not "Clean solution and then One click publish"
The exact error is as follows:
Error 11 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.
I suspect it's something to do with the Web.Config in the Views folder, but then why only after I build once previously. And just to note, the app works fine once published.
i had the same problem with my MVC apps. it was frustrating because i still wanted my views to be checked, so i didn't want to turn off MvcBuildViews
luckily i came across a post which gave me the answer. keep the MvcBuildViews as true, then you can add the following line underneath in your project file:
<BaseIntermediateOutputPath>[SomeKnownLocationIHaveAccessTo]</BaseIntermediateOutputPath>
And make that folder not in your project's folder. Works for me. It's not a perfect solution, but it's good for the moment. Make sure you remove the package folder (located inside the obj\Debug and/or obj\Release folder) from your project folder otherwise you'll keep getting the error.
FWIW, MS know about this error...
I deleted everything out of my obj/Debug folder and it fixed this error. This allowed me to leave in the
<MvcBuildViews>true</MvcBuildViews>
option in my project file (which comes in handy with the T4MVC T4 template).
Edit:
This can be achieved much easier by simply using the "Build" -> "Rebuild Solution" menu (because what rebuild actually does is clear the obj/Debug folder and then build solution).
I'm using this workaround on the MS Connect page for this error. It cleans all obj and temp files under your project (all configurations) before running AspNetCompiler.
Modify the MvcBuildViews target in
your project file so that it depends
on the targets that clean up the
packaging files that Visual Studio has
created. These targets are included in
web application projects
automatically.
All packaging files will be deleted
every time that the MvcBuildViews
target executes.
<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'" DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;">
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(MSBuildProjectDirectory)" />
</Target>
This problem occurs when there is web project output (templated web.config or temporary publish files) in the obj folder. The ASP.NET compiler used isn't smart enough to ignore stuff in the obj folder, so it throws errors instead.
Another fix is to nuke the publish output right before calling <AspNetCompiler>. Open your .csproj and change this:
<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
</Target>
to this:
<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
<ItemGroup>
<ExtraWebConfigs Include="$(BaseIntermediateOutputPath)\**\web.config" />
<ExtraPackageTmp Include="$([System.IO.Directory]::GetDirectories("$(BaseIntermediateOutputPath)", "PackageTmp", System.IO.SearchOption.AllDirectories))" />
</ItemGroup>
<Delete Files="#(ExtraWebConfigs)" />
<RemoveDir Directories="#(ExtraPackageTmp)" />
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
</Target>
That will delete all web.configs under \obj, as well as all PackageTmp folders under \obj.
If you are using Web Publish, you can set MvcBuildViews=false and PrecompileBeforePublish=true, which precompiles after the copy to the temporary folder (immediately before publish/package).
NOTE: PrecompileBeforePublish is only supported by the "new" Web Publishing Pipeline stack (VS2010 SP1 + Azure SDK or VS2012 RTM). If you're using VS2010 RTM, you'll need use one of the alternative methods.
Regarding the solution by jrummell, the setting:
DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;"
It works in VS 2010, but not in VS 2012. In 2012 you have to put:
DependsOnTargets="CleanWebsitesPackage;CleanWebsitesWPPAllFilesInSingleFolder;CleanWebPublishPipelineIntermediateOutput"
Source:
VS 2010:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
VS 2012:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets
I know this has been answered but I just wanted to add something interesting I found.
I had set the "MvcBuildViews" to false in the project, deleted all bin and obj folders and I was still getting the error. I found that there was a ".csproj.user" file that still had "MvcBuildViews" set to true.
I deleted the ".csproj.user" file and then it all worked.
So make sure if you are changing your csproj file that you either change or delete the ".csproj.user" file also.
I had this problem as well, so I created a Pre-Build Event in the project properties to Clean the output directories(${projectPath}\bin,${projectPath}\obj\${ConfigurationName}). On another project I was also getting this error, even with the cleaning event in place. On the second project I was compiling the views as listed in the project file:
<MvcBuildViews>true</MvcBuildViews>
I changed the true to false, and it no longer complained about that error, but still ran correctly. I won't claim I know exactly what was causing the second error, but at least it got me moving forward for the time being.
The problem has to do with the intermediate files, but there is another solution which consist in cleaning up those intermediate files before builnding the views.
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 non-standard 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:
<!--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. I also simplified the target, by removing the PropertyGroup and simplifying the condition, like this:
<Target Name="CleanupForBuildMvcViews" Condition="'$(MVCBuildViews)'=='true' " BeforeTargets="BuildViews">
<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>
In my case i saw that when i have MvcBuildViews and PrecompileDuringPublish as both true - was what was causing this issue.
So i removed the PrecompileDuringPublish and that solution worked for me and i have not faced this problem since.
Related
I need to build a solution, but exclude one project. How should I do it?
I searched a lot about this issue, but nothing could help.
An ItemGroup section rises the following exception:
Invalid element . Unknown task or datatype.
PropertyGroup also rises the exception.
Below is my code sample:
<project name="TI 8.1.6 build script">
<ItemGroup>
<Solution Include="${ROOT}\Core\TI Core.sln" Exclude="${ROOT}\Utilities\DTS Indexing Service\Tdi.Origami.IndexUpdaterServiceSetup\Tdi.Origami.IndexUpdaterServiceSetup.wixproj"/>
</ItemGroup>
...
</project>
How can I do this?
You can exclude projects at the solution level for a specific build configuration by using the Configuration Manager Dialog in Visual Studio:
Then you can simply invoke msbuild on the solution file specifying the build configuration to use:
msbuild /property:Configuration=Release MySolution.sln
The solution suggested by Enrico is the most versatile solution that would work always. An alternative solution might be to use a <MSBuild> task directly. This will work for you if you have all your project files under a particular directory, or be able to easily enumerate all projects you want to build (i.e. number of projects in your solution is not very big).
For example, this MSBuild file will build every project under your current directory except for a specific project:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<MyProjectReferences Include="**\*.*proj" />
<MyProjectReferences Exclude="Utilities\DTS Indexing Service\Tdi.Origami.IndexUpdaterServiceSetup\Tdi.Origami.IndexUpdaterServiceSetup.wixproj" />
</ItemGroup>
<Target Name="BuildAllExceptWixProject">
<MSBuild Projects="#(MyProjectReferences)" Targets="Build" />
</Target>
</Project>
Then you can build that using command line msbuild <myproject> /t:BuildAllExceptWixProject
In your solution file (.sln), remove the Build.0 entries. For example:
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "MyProject", "MyProject.vcxproj", "{2281D9E7-5261-433D-BB04-176A61500CA3}"
EndProject
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{2281D9E7-5261-433D-BB04-176A61500CA3}.Debug|x86.Build.0 = Debug|x64
If you delete this "Build.0" entry, it will load in the solution fine, but will not be built, either through the GUI or via external MSBuild.
Since VS 2019 and MSBuild 16.7, the right way is to use Solution filters. Ref
create a master.proj file:
in another ItemGroup add DefaultExclude properties for programs - put it in front of the solution
-- BA was Canadian
Configuration=Release
Release
drop the master.proj into the directory with the programs and msbuild the master.proj
compiles everything except... that HelloWorld
We're using an AfterBuild target in the vbproj to replace the config file depending on the selected configuration :
<Target Name="AfterBuild" Condition="'$(Configuration)' != 'Release'">
<Delete Files="$(TargetDir)$(TargetFileName).config" />
<Copy SourceFiles="$(ProjectDir)$(Configuration).config" DestinationFiles="$(TargetDir)$(TargetFileName).config" />
</Target>
As an example, let's say we have 3 configurations : Debug, Test, Release. Debug is the local debugging configuration. Test is a pre-production environment used for user-acceptance tests. Release is our production environment.
In the App.config file, we store the configuration for our Release environment. In the Debug.config file, we store the configuration for our local debugging needs. In the Test.config file, we store the configuration for our user-acceptance environment.
The goal of the AfterBuild target is to replace the Release configuration (App.config) when building/executing with the Debug configuration (Debug.config) or the Test configuration (Test.config).
Everything works as intended when we publish the application (Release, App.config) or if we build the application and launch the bin\<appname>.exe (Debug or Test).
However, if we Start the application from Visual Studio, with the Visual Studio hosting process, the correct configuration is copied to bin\<appname>.exe.config, but it seems that Visual Studio doesn't copy the correct configuration to bin\<appname>.vshost.exe.config. We tried cleaning the solution, performing a Rebuild before debugging, manually deleting the bin\<appname>.vshost.exe.config file before launching, but it seems that the hosting process always copies the configuration from the default App.config file. The same problem happens whether we try to Start with the Debug configuration or the Test configuration.
To add to the confusion, we created multiple test projects, using the same AfterBuild target, and some of them work correctly, others don't. All projects are using .Net Framework 4.5.1, but we also reproduced the problem with .Net 4.5. It doesn't seem to be caused by the project type, since we're able to reproduce the issue with a Console Application as well as a Windows Forms Application.
What could be causing the problem?
Alternatively, could we use another solution to manage the configuration for each of our environment?
Notes
We use the default App.config file for our Release environment
because ClickOnce doesn't seem to support AfterBuild targets.
We use Visual Studio Express 2013 for Windows Desktop, so we can't use any plugin like SlowCheetah.
Following Steve's suggestion, we moved the logic to the BeforeCompile target, specifying to replace the App.config depending on the selected configuration :
<Target Name="BeforeCompile">
<Delete Files="$(ProjectDir)App.config" />
<Copy SourceFiles="$(ProjectDir)$(Configuration).config" DestinationFiles="$(ProjectDir)App.config" />
<Output TaskParameter="DestinationFiles" ItemName="FileWrites"/>
</Copy>
</Target>
It wouldn't replace the file every time, and when it did, it didn't necessarily apply to the <appname>.vshost.exe.config file. We stumbled on another answer which guided us on the right path : Can Visual Studio automatically adjust the name of other file as it does with app.config?
Adding the following <Copy> command, we achieved the desired behavior :
<!--
Copy the application's .config file, if any.
Not using SkipUnchangedFiles="true" because the application may want to change
the app.config and not have an incremental build replace it.
-->
<Copy
SourceFiles="#(AppConfigWithTargetPath)"
DestinationFiles="#(AppConfigWithTargetPath->'$(OutDir)%(TargetPath)')"
OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
Retries="$(CopyRetryCount)"
RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"
UseHardlinksIfPossible="$(CreateHardLinksForAdditionalFilesIfPossible)"
>
<Output TaskParameter="DestinationFiles" ItemName="FileWrites"/>
</Copy>
We now have a config file for each configuration (Debug.config, Test.config, Release.config). Visual Studio replaces the App.config file with the correct one on each build/launch. The resulting <appname>.vshost.exe.config file contains the correct parameters.
Bonus
The underlying benefit with this solution is that we have one config file per configuration, so we can update the .vbproj file and replace, for example,
<None Include="Debug.config" />
<None Include="Release.config" />
with
<None Include="Debug.config">
<DependentUpon>App.config</DependentUpon>
</None>
<None Include="Release.config">
<DependentUpon>App.config</DependentUpon>
</None>
All config files will be grouped under the main App.config file in Visual Studio :
For me it helped to disable VisualStudio hosting process.
Remove the check mark in:
Project -> Preferences -> Debug -> Enable Visual Studio hosting process
This stops Visual Studio from overwriting the *config file.
I'm totally stumped by this one. The ideas that I've found through google stack overflow don't work for me and I've no idea why.
We recently upgraded the project to Visual Studio 2012 and MVC 4 with .NET 4.5 and now it won't publish properly.
We have another branch that just has the project publishing in Visual Studio 2012 without the upgrade to MVC4 or .NET4.5 and that seems to work, so I'm guessing it isn't a Visual Studio issue. Just something with the way that MVC 4 is set up in our project. MVC 3 was added by referencing the DLLs directly from a lib folder we had created in the source control (but outside of any projects). MVC 4 is added via NuGet.
The issue is that System.Web.Helpers (amongst others) don't appear in the bin directory of the published application. This means that when it is put on the test server it won't run as the DLL is missing.
I've set Copy Local to be TRUE (actually, it already was, but I turned if off and on again). I also read somewhere that if the file exists in the GAC it won't matter what this setting is, it won't copy. However, I've checked and it isn't in the GAC.
I've ensured that the reference in the MVC application was pointing to the version of the file in the NuGet packages folder. (It wasn't originally, but I've manually edited the csproj file to do that as removing and readding the NuGet package didn't help)
I've added a post-build event to copy the relevant files (which doesn't affect the publish, although they are in the project's bin directory)
I've attempted to put a _bin_deployableAssemblies folder in place, as per Phil Haack's blog, but it seems this doesn't work in Visual Studio 2012.
I've tried modifying the csproj file (which is just an MSBuild file) to copy the relevant files for me, as per this SO answer. But for what ever reason that doesn't want to work either.
I've run out of things I can try. Well, I can always copy the file manually as some SO answers have suggested elsewhere, but that defeats the purpose.
Any ideas?
UPDATE
Added more things in the bullet points above for things I've tried that don't work for me.
How about this:
Right-click on the MVC project in solution explorer.
Add Deployable Dependencies
Tick MVC
I've found an answer. It is a bit of a hack because I couldn't get the MSBuild copy command to work, so I used the Exec command to get xcopy to do the copying for me.
First of all I added a folder called _bin_PublishAssemblies to the project and put in there the assemblies that I need to publish that the build process is not picking up already.
Then I added the following towards the end of the csproj file:
<Target Name="AfterBuild">
<Message Text="Build | Copying assemblies to output folder ($(OutputPath))" Importance="high" />
<Exec Command="ECHO Going to copy from '$(ProjectDir)\_bin_PublishAssemblies'" />
<Exec Command="xcopy $(ProjectDir)\_bin_PublishAssemblies\* $(OutputPath) /Y" />
</Target>
<Target Name="CopyBinFiles" AfterTargets="CopyAllFilesToSingleFolderForPackage" BeforeTargets="MSDeployPublish">
<Message Text="Deploy | Copying assemblies to output folder ($(_PackageTempDir)\bin\)" Importance="high" />
<Exec Command="ECHO Going to copy from '$(ProjectDir)\_bin_PublishAssemblies'" />
<Exec Command="xcopy $(ProjectDir)\_bin_PublishAssemblies\* $(_PackageTempDir)\bin\ /Y" />
</Target>
I have MyLib library project along with several examples. The library and examples are in the same solution MySolution.
In MyLib library project I have included MSBuild code to zip the whole solution and copy to another directory for internet publishing.
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<Target Name="AfterBuild" Condition="'$(Configuration)' == 'Release'">
<PropertyGroup>
<ReleasePath>C:\Users\Administrator\Projects\CA\Libraries\Api-DotNet\</ReleasePath>
<ZipFile>C:\Users\Administrator\Projects\CA\WebProject\libraries\Api-DotNet.zip</ZipFile>
</PropertyGroup>
<ItemGroup>
<LibraryFiles Include="$(ReleasePath)\**\*.*" Exclude="$(ReleasePath)\**\*.user;$(ReleasePath)\**\*.suo;$(ReleasePath)\Api.*;$(ReleasePath)\**\packages\**;$(ReleasePath)\**\Lib.Test\**;$(ReleasePath)\**\*.nuspec;$(ReleasePath)\**\*.nupkg;$(ReleasePath)\**\*nuget*;$(ReleasePath)\**\*internal*;$(ReleasePath)\**\*ReSharper*\**;$(ReleasePath)\**\.svn\**;$(ReleasePath)\**\obj\**;$(ReleasePath)\lib\bin\Debug\**;$(ReleasePath)\lib\bin\Publish\**;$(ReleasePath)\Example\**\bin\**;" />
</ItemGroup>
<Zip Files="#(LibraryFiles)" WorkingDirectory="$(ReleasePath)" ZipFileName="$(ZipFile)" ZipLevel="9" />
</Target>
</Project>
The problem is that when user download library and run on another computer the compiler show error that import library not found MSBuild.Community.Tasks.Targets. I would like to exclude ZipAndCopy code from project file when building the solution. How to do that?
Add this Condition to both the Import and the Zip elements:
Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')"
For example:
<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"
Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')" />
Similar to this: C# Checking if a Property 'Starts/Ends With' in a csproj
The above solution hides the project file load error, but Tomas appears to be trying to use a Task from the MSBuild.Community.Tasks extension.
This should be installable by using NuGet. Here's a link to the source site showing we can install it via NuGet's Package Command Line:
PM> Install-Package MSBuildTasks
Their documentation isn't great. You'll need to also define the path using:
<Import Project="..\Packages\MSBuildTasks.1.4.0.88\tools\MSBuild.Community.Tasks.Targets"/>
<UsingTask AssemblyFile="..\Packages\MSBuildTasks.1.4.0.88\tools\MSBuild.Community.Tasks.Targets.dll"
TaskName="MSBuild.Community.Tasks.Zip" />
...where you need to replace the Version with the Version you are using from NuGet. It's not perfect, but I managed to get mine working.
NuGet will install it into your 'Packages' folder under the root of your Solution/Project Trunk.
I ran into issues where Visual Studio may still be fighting to look for the files in a specific location. If this happens, copy the files from '.\Packages\MSBuildTasks.1.4.0.88\tools*' to 'C:\Program Files (x86)\MSBuild\MSBuildCommunityTasks\'.
This isn't the most elegant, but I was able to successfully get the new Tags to work. If I find a way to fix this last part, I'll update my posting.
Sounds like you want multiple build configurations. I would suggest setting up one specifically for building and zipping the artifacts and a separate for your users.
Release ZIP could be your build with the post-build-event to zip your files, and Release could be an ordinary build that doesn't do anything special using the community tasks.
Background:
We're using a 3rd party tool in our .NET C# solution. This tool has it's own syntax and integrates with Visual Studio. When we use this tool we write its markup within Visual Studio and then when we build the solution the custom tool runs and generates a .cs file based on the markup we have written.
This generated source file contains a version number which is causing problems when we check these in to version control (Endless conflicts). Our understanding is that it's considered best practice not to check in generated source files.
So we excluded the generated .cs files from SVN and then the next issue we ran in to was that the Visual Studio solution referenced these files, so when TeamCity (Our continuous build/integration software) went to build the solution it would fail straight away as it couldn't find these files.
We then removed these from the solution as well as excluding them from SVN, this fixed the original issue, we're no longer checking in generated code and it builds fine in TeamCity (As the files are re-generated with every build).
We now have a new problem - As the generated files are no longer included in the solution, intellisense and code inspection fails as the generated classes cannot be found. The solution builds just fine (As again the code is re-generated during the build).
Question
Is there a way to tell ReSharper to include generated .cs files in its code inspection? These files are external to the solution but they are in the obj directory.
Cheers,
Tyler
We had a similar problem and couldn't come up with a good solution so I wrote a ReSharper extension to include external code:
https://resharper-plugins.jetbrains.com/packages/ReSharper.ExternalCode
As mentioned in my comment, one workaround is to keep the generated files in the solution (but not in source control), while adding a pre-build step to create empty .cs files (if the real generated file isn't present) so that the file is always available during a build.
In my projects, I use the following MSBuild targets to generate empty files by using the Touch task. You may need to make some modifications - in my case, the target files are actually defined within a project not at the solution level; and the build action for the files is set to "None" which is important to understand how these targets work.
<?xml version="1.0" encoding="utf-8" ?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
<!--
Creates empty 'dummy' files for any files that are specified but do not exist.
To be processed, the following must be true:
1. The file is included in an ItemGroup called CanCreateDummy, e.g.
<ItemGroup>
<CanCreateDummy Include="SomeFile.cs" />
</ItemGroup>
If you want to specify a CanCreateDummy file in the .csproj file, you would
modify the above slightly as follows to prevent it appearing twice:
<ItemGroup>
<CanCreateDummy Include="SomeFile.cs">
<Visible>false</Visible>
</CanCreateDummy>
</ItemGroup>
2. The file is included in the ItemGroup called None. This is normally performed
by adding the file to the project in the usual way through Visual Studio, and
then setting the file's Build Action property to None.
-->
<Target
Name="CreateDummyFiles"
AfterTargets="BeforeBuild"
>
<!--
This voodoo creates the intersection of 2 lists - #(CanCreateDummy) and #(None)
(this latter item is defined in the project file). We want to create a filtered
list of all items that are in both these lists, which is called _ProjectDummyFiles.
See http://blogs.msdn.com/b/msbuild/archive/2006/05/30/610494.aspx for how the
Condition voodoo works.
-->
<CreateItem Include="#(CanCreateDummy)" Condition="'%(Identity)' != '' and '#(None)' != ''" >
<Output TaskParameter="Include" ItemName="_ProjectDummyFiles"/>
</CreateItem>
<Message
Text="Creating dummy settings file #(_ProjectDummyFiles)"
Condition=" !Exists('%(_ProjectDummyFiles.FullPath)')"
/>
<Touch
AlwaysCreate="true"
Files="#(_ProjectDummyFiles)"
Condition=" !Exists('%(_ProjectDummyFiles.FullPath)')"
/>
</Target>
</Project>
Hope this helps
Rich