Deploying a Web Application Project from VS2010 RTM causes an error in MSBuild. It complains that the PipelinePreDeployCopyAllFilesToOneFolder target cannot be found.
Is there any way to further diagnose this?
Thank you.
I had the same problem and when I looked in the .csproj file for my web application I had the following lines...
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="'$(Solutions.VSVersion)' == '8.0'" />
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" Condition="'$(Solutions.VSVersion)' == '9.0'" />
I guess this happened since I had recently upgraded from VS2008 to VS2010. So it looks like the during the conversion process it got all screwed up. To fix it I just replaced those lines with ...
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
After that everything worked as it should.
I've seen the answer given by brodie in several places online, which is strange to me because this task (PipelinePreDeployCopyAllFilesToOneFolder) is not even contained in this target (Microsoft.WebApplication.targets):
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
If you actually go and find this file (on an x64 machine it's in C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets, or the version 12.0 equivalent if you're using VS2013) and open it in a text viewer, you'll see it's not there..
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).
So to get this into your MSBuild/.csproj file, include the following:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" />
Do you have Visual Studio 2010 installed on the machine where you are trying to build? If so then look for a file located at %Program Files(x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets it should have that target. If it doesn't then those files may have been corrupted and probably reparing your VS 2010 install should fix it.
I think the Web Deployment targets/tasks are shipped with VS itself and not the .NET framework, so you need VS installed (or you can manually configure the machine)/
Even though this is an old post It still provided some great help!
My setup is using a remote host for Automation of a project built in VS2013.
The remote host doesn't contain all the VS2013 targets when you solely install MSBuild 12.0 and this resulted in the 'Microsoft.Web.Publishing.targets' file not existing.
To get around this target error I had to copy the files from my local VS2013 path and copy this to the remote host in the equivalent location.
Related
All of a sudden, I am getting the following errors for 3 projects in a solution:
Error NU1105 Unable to find project information for 'C:\code\example\src\libs\example.I18n\example.I18n.csproj'.
The project file may be invalid or missing targets required for restore.
The only thing that has changed in the project is a couple of DB changes, but I never had any issues in the past. The only other thing is that I updated to Visual Studio 2017 15.5. Could that cause issues?
I have tried removing and recloning the solution from source control, but still getting errors. No problems on my colleagues' machines, so it must be something local.
Example of one of the .csproj files if this helps:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net452</TargetFramework>
<AssemblyName>Example.I18n</AssemblyName>
<PackageId>Example.I18n</PackageId>
<GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
<GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
<GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="1.1.2" />
<PackageReference Include="Microsoft.Extensions.Logging" Version="1.1.1" />
<PackageReference Include="MessageFormat" Version="1.0.1" />
</ItemGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'net452' ">
<Reference Include="System" />
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
</Project>
I also got the same after upgrading to version 15.6 of Visual Studio 2017.
Closing VS and deleting the .vs folder fixed it for me.
For me, the casing of the project file on disk did not match the casing in the solution file.
Say I had a solution with LibraryA.csproj and LibraryB.csproj, where LibraryB.csproj has a reference to LibraryA.csproj. Having an incorrect casing for LibraryA.csproj in the solution file would cause NU1105 when building LibraryB.csproj:
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "LibraryA", "LibraryA\Librarya.csproj", "{24DEBB3B-762A-491D-8B83-6D078C0B30C0}"
I started seeing this problem after upgrading to version 15.5 of Visual Studio 2017. I did not encounter this problem with version 15.4.5.
I had this problem and I just followed what the error message recommends inside VS:
to restore the solution.
So I opened a command line or package manager console, chdir into the directory with the solution (.sln) file and just issued
C:> dotnet restore .\mySolution.sln
Problem was fixed.
This error message will also occur if a referenced project is not included in the solution. I encountered this problem today, and I found the fix here.
I encountered this error when having a duplicate reference to a project.
<ProjectReference Include="..\ProjectA.csproj" />
<ProjectReference Include="..\ProjectA.csproj" />
Removing the duplicate reference resolved the error.
What worked for me was to
Remove the offending project
Build the solution
Re-add the project.
Seems that some projects were removed from solution file (don't know why). Fixed by undoing these solution file changes
I have next project structure (.Net Core projects):
../classLib
../../../webProject1
../../../webProject2
../../myWebProjects.sln
webProject1 and webProject2 reference classLib as project itself (not as .dll). When I opened my solution in VS 2019 and tried to build I got identical error NU1105: Unable to find project information for '../classLib.csproj'. error.
Before build depended projects you need to restore there dependency. What I did, just add
next Target to my webProject1.csproj and webProject2.csprojfiles.
<Target Name="PreBuild" BeforeTargets="PreBuildEvent">
<Exec Command="dotnet restore" />
</Target>
Open powershell and running restore command solved my issue.
dotnet restore Sample.sln
I correct this error by simply running the clean solution option.
Right click the solution in the solution explorer and choose clean solution.
This is insane, i tried all this:
updated VS. manually deleted all bin folders, run dotnet restore, clean rebuild nothing works
solution: finally i unload all the projects and start reloading them into solution, one by one in the order they show dependency errors. then the last one just cascade fixes everything. No idea what was wrong
I recently came across Error NU1105 while using JetBrains Rider on Linux. So this involves Mono and the MSBuild version that comes with it.
It turns out this was being caused by my solution files being in a directory that was a symbolic link to another directory. I believe MSBuild was dereferencing the linked directory and instead referencing the source directory. This makes some of the referenced paths completely different, even though they are the exact same files, case, everything else. Opening the solution from the original location works perfectly now for me.
Reload the project which causes the problem, this will fix the issue,
As mentioned in the following link :
https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu1105
This happend to me when I had files with names exceeding OS's max path limit. Check your names ;)
In my case I did it and it worked for me
goto Tools/CommandLine/Developer Command Prompt or Developer Powershell
type this command and Enter "dotnet restore".
Build your solution
That's all
Just use: "dotnet restore MySolution.sln",
Where MySolution.sln is your solution.
I was getting this error error NU1105: Unable to find project information for 'C:\folder2\project1.csproj'.
but project1 that I had as part of the solution was located in C:\folder1\project1.csproj (it was also there in c:\folder2\project1.csproj too but not part of the solution, so it was confusing)
Once I changed the reference to the correct location of the project it worked.
After spending 3 hours, trying out numerous solutions, what worked for me is that I had to undo my root solution sln file...some of the project references were removed..not sure how.
Has anyone seen this error and know how to fix it?
The "TransformXml" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll.
Could not load file or assembly 'file:///C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll' or one of its dependencies. The system cannot find the file specified.
Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
I read elsewhere that the problem is when you don't have SQL Server installed. But I do have SQL Express 2012 x64 installed with SP1. I am also running VS 2013 Professional.
I have ran this exact same solution in VS 2012 express with no problems.
The answers provided by Dai Bok and emalamisura work fine as long as you use Visual Studio 2012.
For VS 2013 this fails as well. In order to make this work with all versions of Visual Studio you should:
Open the project file (.csproj) of the project failing to load
Search for <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" />
Change it to <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.targets" />
Reload the project
That will set the correct version of Visual Studio dynamically and properly.
To get mine to work, I just copied my v10.0 folder and renamed it to v11.0, and things seems to work well from then on. That's the quick fix for now.
As this is probably not the best solution, and although it works, I was going to try installing the Microsoft Windows SDK for Windows 7 and .NET Framework 4 Windows SDK for Windows 7 and .NET Framework 4, but it is taking to long to download.
To fix the issue,
Find the Visual studio Installer in your computer
Click or tap to start the installer, and then select Modify.
From the Individual Components screen, select Asp.net and web development tools and then select Modify/Install.
This solved the issue as it creates the dll's in the mentioned path.
I've been combating this problem on our build server for several days, so I figured I'd document the resolution I came to. First, my build server has the web publishing extensions installed. I can use the TransformXml task to my heart's content inside of a web application project.
To use it outside of a web application project, I tried to add the UsingTask element to my project and point it to the right place using ms build properties (as Benjamin demonstrated). However, they weren't there on my build server (those with easy access to the file system of their build server can probably skip this and just install the relevant package to Visual Studio). I even went so far as to hard code visual studio versions, but it always dropped that error on me.
I finally gave up, pulled the DLLs from my local PC:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.Tasks.dll
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.XmlTransform.dll
I uploaded them to source control and added that folder to my build's workspace (Edit Build Definition -> Source Settings -> Source Control Folder). From there, I don't even need to reference the folder -- here's what my UsingTask looks like:
<UsingTask TaskName="TransformXml" AssemblyFile="Microsoft.Web.Publishing.Tasks.dll" />
Now I can use the TransformXml task to my heart's content from any project.
For VS2019
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(MSBuildToolsVersion
I replaced MSBuildToolsVersion with VisualStudioVersion.
Because there are only v12.0, v14.0 and v15.0 in my VisualStudio folder, I edit my project file and change the reference path from v10.0 to v14.0. Then the project builds successfully.
Before:
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
After:
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
Solutions provided seem to work for using VS as an IDE, but if you use DotnetCore via CLI or on a unix based system this does not work.
I found that the following seem to work
<PropertyGroup>
<XmlTransformDllPath Condition="'$(XmlTransformDllPath)' == '' AND '$(MSBuildRuntimeType)' == 'core'">$(MSBuildSDKsPath)/Microsoft.NET.Sdk.Publish/tools/net5.0/Microsoft.NET.Sdk.Publish.Tasks.dll</XmlTransformDllPath>
<XmlTransformDllPath Condition="'$(XmlTransformDllPath)' == '' AND '$(MSBuildRuntimeType)' != 'core'">$(MSBuildSDKsPath)/Microsoft.NET.Sdk.Publish/tools/net472/Microsoft.NET.Sdk.Publish.Tasks.dll</XmlTransformDllPath>
<XmlTransformDllPath Condition="!Exists($(XmlTransformDllPath))">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll</XmlTransformDllPath>
</PropertyGroup>
<UsingTask TaskName="TransformXml" AssemblyFile="$(XmlTransformDllPath)" />
This solution takes into account netcore, full .net
For some reason MSBuildSDKsPath and MSBuildExtensionsPath32 are different on windows when using CLI vs VS2019
CLI:
MSBuildSDKsPath = C:\Program Files\dotnet\sdk\5.0.103\Sdks
MSBuildExtensionsPath32 = C:\Program Files\dotnet\sdk\5.0.103
Vs2019
MSBuildSDKsPath = C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Sdks
MSBuildExtensionsPath32 = C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild
Which on my Mac returns /usr/local/share/dotnet/sdk/5.0.201
Only problem I see is with the tools/net5.0 part of the name which changes ever release
Also created https://github.com/dotnet/sdk/issues/16469 and answers this on The "TransformXml" task was not found (error MSB4036) on TeamCity build
The correct answer to this is to unload the project in question and then edit the csproj file, look for an entry where they are referencing the 10.0 path and change it to point to 11.0 instead.
You need two things to make it work:
1) Install Visual Studio Build Tools (You don't need the whole Visual Studio, only the VS Build Tools) with selected "Web development build tools" option on your build server
https://www.visualstudio.com/pl/thank-you-downloading-visual-studio/?sku=BuildTools&rel=15
2) Ensure that path to Microsoft.Web.Publishing.Tasks.dll is correct
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(MSBuildToolsVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
For me it started working just by adding reference to the NuGet package MSBuild.Microsoft.VisualStudio.Web.targets v14.0.0.3
Even no need to add UsingTask element to the project file as it mentioned by the package author
https://github.com/pdonald/nuget-webtargets
Just install the NuGet package. The package automatically sets the
$(VSToolsPath) property to use the targets file in the tools folder.
And then I was able to use TransformXml and other tasks, defined in the package, for instance to transform app.config
<Target Name="app_config_AfterCompile" AfterTargets="AfterCompile" Condition="Exists('app.$(Configuration).config')">
<!--Generate transformed app config in the intermediate directory-->
<TransformXml Source="app.config" Destination="$(IntermediateOutputPath)$(TargetFileName).config" Transform="app.$(Configuration).config" />
<!--Force build process to use the transformed configuration file from now on.-->
<ItemGroup>
<AppConfigWithTargetPath Remove="App.config" />
<AppConfigWithTargetPath Include="$(IntermediateOutputPath)$(TargetFileName).config">
<TargetPath>$(TargetFileName).config</TargetPath>
</AppConfigWithTargetPath>
</ItemGroup>
</Target>
Just in case someone is using an SDK-style csproj, you can achieve this without having to install Visual Studio on the build server.
First you should install the SlowCheetah nuget package to your project. Once you install it, you'll see the following in your SDK-style project.
<PackageReference Include="Microsoft.VisualStudio.SlowCheetah" Version="3.2.20">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
</PackageReference>
Then make sure you add the GeneratePathProperty="true" attribute (see below). This is very important for the next part because it'll help you grab the path of where the nuget package is restored on your machine. George Dangl explains it in his article here.
<PackageReference Include="Microsoft.VisualStudio.SlowCheetah" Version="3.2.20" GeneratePathProperty="true">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
</PackageReference>
Import the SlowCheetah targets into your project:
<Import Project="$(PkgMicrosoft_VisualStudio_SlowCheetah)\build\Microsoft.VisualStudio.SlowCheetah.targets" />
You can now use an target command (in this case after publish) to apply some custom transformations. If you need to, you can always hard-code the file names below instead of using the variables in the below example.
<Target Name="AfterPublishs" AfterTargets="Publish">
<TransformTask Source="Web.config" Transform="Web.$(Configuration).MyCustomTransformFile.config" Destination="$(PublishDir)\Web.config" />
</Target>
If you haven't used SlowCheetah before, I recommend checking it out. They have a Visual Studio extension that will make it easier for you to preview transform files.
I installed Visual Studio 2010 SP1 the other day and now when i try to "publish" my apps i get this error on ALL of my projects.
The target "_CopyBinDeployableAssemblies" does not exist in the project.
I have no idea what the problem is here and i find nothing on the all mighty Google and that makes me a bit nervous.
Can anyone point me in the right direction here or maybe somebody else has the same problem? Because it happens in all of my projects so i'm kind of amazed im alone with this problem.
The sites are ASP.NET Web Applications, some of them are mixed Web forms/MVC but one is only Webforms. 1 site is super mega simple with almost no references and i still get the error.
I also experienced this problem after installing Visual Studio 2010 SP1 Beta.
The missing target _CopyBinDeployableAssemblies is defined in:
$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets
I solved the problem by adding an <Import> element to the broken project files.
So if you have a depdendency on the above targets, which you can find out by looking for the following <Import> in your project files:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" />
You need to also import:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
From joao-angelo's blog post, add the following to the project file (.csproj/.vbproj)
<Target Name="Noop"></Target>
<PropertyGroup>
<CollectFilesFrom_binDeployableAssembliesDependsOn>
Noop
</CollectFilesFrom_binDeployableAssembliesDependsOn>
</PropertyGroup>
before importing
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" />
That works for me using ClickOnce on VS2010 SP1 using App.config transform
Hoho, Jacob is right!
When we install VS 2010 SP1 the default MSBuild path will focus to folder
[C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0]
not
[C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0] any more.
And the [Microsoft.WebApplication.targets] file has a build target named [_CopyBinDeployableAssemblies].
So we just add a [_CopyBinDeployableAssemblies] target to our project file(can open it with Notepad :))
, the problem was solved
Ex: <Target Name="_CopyBinDeployableAssemblies"></Target>. Just need an empty target :)
The answer given above by Ragge was what I needed. But in my case, I only added the second line. The first line Ragge gave was already in the project file.
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
It's VS 2013 SP 3 and I'm still having this issue!
In order to fix it I had to change the following line in the failing to build projects from:
<Import Project="$(VSToolsPath)\Web\Microsoft.Web.Publishing.targets" Condition="'$(VSToolsPath)' != ''" />
to the following line:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
Well, spent 4h on this today and i solved it now. But unfortunately i do not have a definite answer what the problem was. Buit i will describe what i did.
Uninstalled SP 1 and got a couple errors. These where because i didn't have the VS install media and it where asking for it.
SP1 seemed to have been removed but i still got the error.
Downloaded VS Ultimate Trial and tried to do a repair, didn't help.
Downloaded VS 2010 SP1 again and installed it. Still the same problem.
Uninstalled VS SP1 with access to VS Ultimate install media and i only got one error where it needed some VS Express stuff, i pressed cancel on that one and it said the uninstall failed.
Launched Visual Studio and the problem where gone! Hallelujah!
And well, i don't blame MS for this at all. I knew it where a beta but i never had issues like this before.
Hope this solves the problem for somebody else.
The answer Ragge gave worked for us as well. I had a solution I hadn't opened since SP1 install that just refused to build with the same error. Edited the project file in Notepad to include those two statements and viola! issue solved. Thanks so much for your diligence!
Addition: A colleague mentioned that the addition of the import will cause builds happening outside of Visual Studio to likely complain (Command line msbuild, build server) because Microsoft.WebApplication.targets doesn't exist there. So we changed the import line to read:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="$(BuildingInsideVisualStudio) == true AND exists('$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets')" />
These conditions were important for our builds as we do all deploys using the build server and msdeploy.
Undeploy the project and edit and add following code in project file at end of <Import>
<Target Name="_CopyBinDeployableAssemblies"
Condition="Exists('$(MSBuildProjectDirectory)\_bin_deployableAssemblies')">
<CreateItem Include="$(MSBuildProjectDirectory)\_bin_deployableAssemblies\**\*.*"
Condition="Exists('$(MSBuildProjectDirectory)\_bin_deployableAssemblies')"
Exclude="$(MSBuildProjectDirectory)\_bin_deployableAssemblies\.svn\**\*">
<Output ItemName="_binDeployableAssemblies" TaskParameter="Include" />
</CreateItem>
<Copy SourceFiles="#(_binDeployableAssemblies)"
DestinationFolder="$(OutDir)\%(RecursiveDir)" SkipUnchangedFiles="true"
Retries="$(CopyRetryCount)"
RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />
</Target>
I'm using Vs2010 and Wix 3.6.0917.0, for the record. I use the $(SolutionDir) property quite a bit in my .wixproj file, since I only ever build the installer as part of a solution build or as part of a team build, and never by itself. However, while building from the command line works just fine (both from cmd on the desktop and when building on build agents), when I attempt to reload the .wixproj file into the IDE, I get errors because all the $(SolutionDir) variables are resolving to the project directory, not the solution directory. Consider:
C:\workspace\projectCollection\teamProject\branch\solution.sln
C:\workspace\projectCollection\teamProject\branch\source\installer\installer.wixproj
and assume a shared custom targets file:
C:\workspace\projectCollection\teamProject\branch\build\shared.targets
which is referenced inside installer.wixproj with:
<Import Project="$(SolutionDir)build\shared.targets">
Command line builds work fine...
C:\workspace\projectCollection\teamProject\branch\> MSBuild /t:build /property:Platform=x64;Configuration=Debug solution.sln
0 Errors
0 Warnings
Build succeeded!
But load into vs2010 and you see...
The imported project
"C:\workspace\projectCollection\teamProject\branch\source\installer\build\shared.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
C:\workspace\projectCollection\teamProject\branch\source\installer\installer.wixproj
You can see here that the resolved result of $(SolutionDir)build\shared.targets is getting the project directory and not the solution directory. What gives?
My guess would be that $(SolutionDir) resolves to nothing when the wixproj is being loaded into VS2010. In this case the imported file becomes "build\shared.targets". Since the path is relative it is assumed to be relative to the project directory. Using ".." or some other path could get you around the problem.
I verified this failed with WiX 3.5.2222.0 in VS2010. A C# console application project (csproj) worked as expected.
Have you filed a bug against WiX for this?
I looked at the WiX vs2010 addin code a little bit and the Solution properties are only created when doing a build and not when the project is loaded.
I am experiencing a strange issue with VS2010. We use TFS to build our API dlls and we used to reference them in our projects usign a mapped network drive that was fully trusted. We have been working like that for at least two years and everything worked perfectly.
Today, I converted a webapp to vs2010 and when I compile it in Release, it's giving me:
SGEN : error : Could not load file or
assembly 'file:///L:\Api\Release
API_20100521.1\Release\CS.API.Exceptions.dll' or one of its dependencies. Operation
is not supported. (Exception from
HRESULT: 0x80131515)
The strange thing is that it's working when it's under the Debug profile...
I tried adding the
<runtime>
<loadFromRemoteSources enabled="true" />
</runtime>
into app.config and still no luck (See http://social.msdn.microsoft.com/Forums/en/msbuild/thread/d12f6301-85bf-4b9e-8e34-a06398a60df0 and http://msdn.microsoft.com/en-us/library/dd409252(VS.100).aspx)
I am pretty sure that this issue is from visual studio or msbuild, as our code won't run from a network share when in prod because all the referenced dll's are copied into the bin folder.
If anyone has an solution (or just an idea for a search path) please let me know !
Edit : It turns out that it was working in Debug mode because generation of serialisation assemblies was turned Off. As the title say, it's really a SGEN problem since it is this utility that says that the path is not trusted...
I was able to fix this error by finding the assembly DLL in Windows Explorer, right clicking, choosing Properties, and then pressing the "unblock" button. The DLL has a stream that is marking it as an external file - and by clicking unblock you remove that designation.
I just had the same/similar issue on a TFS build server where a build was referencing dll's from a network share.
The problems is that the CLR v4 security policy model has changed since previous versions and are not sandboxing assemblies as before.
To fix your issue just find the location of sgen.exe and create a sgen.exe.config in the same folder with following contents:
<configuration>
<runtime>
<loadFromRemoteSources enabled="true" />
</runtime>
</configuration>
sgen.exe is usually at
"C:\Program Files\Microsoft SDKs\Windows\v[current version]\bin\NETFX 4.0 Tools"
You can read about some of the changes around CAS policies in .NET 4.0 in this blogpost: Link
Had the same problem and the config change didnt work. Only when i set Generate Serialization Assembly to off in the project properties did it work.
I had the same error and found my DLL was "blocked". Open up the DLL in explorer, right click -> properties -> press 'Unblock'.
http://cantgrokwontgrok.blogspot.com/2009/10/visual-studio-unknown-build-error.html
I had this exact same problem and fixed it by adding the sgen.exe.config under C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools
with this simple config as others have said
<?xml version ="1.0"?>
<configuration>
<runtime>
<loadFromRemoteSources enabled="true" />
</runtime>
</configuration>
For those of you running a 64bit version of the TFS build service, I had to create the config file in the following path:
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\x64
And the file contents:
<?xml version ="1.0"?>
<configuration>
<runtime>
<loadFromRemoteSources enabled="true" />
</runtime>
</configuration>
I had the same issue, loaded the assembly in the GAC and worked
Adding the snippet below to the app.config file worked in my case. I'm Running Windows XP, with VS2010 service pack 1.
<configuration>
<runtime>
<loadFromRemoteSources enabled="true" />
</runtime>
</configuration>
In my case bunch of dlls were blocked.
To unblock all files in folder I used power shell with following command
dir -Path [directory path] -Recurse | Unblock-File
Just as an FYI if you are running Windows 7 the sgen.exe file can be found at:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools
I had to create a sgen.exe.config and place it there and then this problem went away.
Neither the unblock nor the config worked for me.
What did the trick for me was this tip about caspol.
I ran
%windir%\Microsoft.NET\Framework\v2.0.50727\CasPol.exe -m -ag 1.2 -url file://UncPathName/UncSubPath/* FullTrust
And I was ready to go, not even a VisualStudio restart required.
I got a similar problem and I finally got over with it by removing the licenses.licx file in the Properties folder of the solution.
Just in case like me, Unblock was not a solution, as Unblock does not appear on my dll file properties. Kept looking and ended up closing my solution file and re-opening using the local C: copy instead of network UNC path to project sln file. Was able to publish after going this route.