I just updated nUnit from 2.6.4 to 3.0.1 on my VS2015. Everything went well with just ONE problem.
In my Test method, I have to load a xml file, let's call it UnitTestConfiguration.xml, it is saved inside the same root folder as the app.Config and package.Config file. With NUnit 2.6.4, this xml file is being found and load perfectly.
But, with Nunit 3.0.1, I receive this error:
System.IO.FileNotFoundException : Could not find file 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 14.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\UnitTestConfiguration.xml'.
So my question is, why would 3.0.1 not look into the root folder of the test project to begin with, but somewhere else? Is there any setting(s) to correct it?
Yes, this is a Breaking Change in NUnit3, tests are no longer ran in the root folder.
Use TestContext.TestDirectory to reach it.
Related
When VS2017 was used to create a stateful solution, producing the standard boilerplate code, the resulting two projects have two different MSBuild versions.
The application uses MSBuild version 1.5.0.
The service uses MSBuild version 1.6.0 (the current "latest").
If I run the solution this way, it runs fine on my local Service Fabric cluster.
But when after I use NuGet to update the application's MSBuild to 1.6.0 (so both application and server projects use the same), the following errors occur.
Severity Code Description Project File Line Suppression State
Error The OutputPath property is not set for project 'gt_strd5.sfproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' P follow a project-to-project reference to this project, this project has belatform='x64'. This error may also appear if some other project is trying toen unloaded or is not included in the solution, and the referencing project does not build using the same or an equivalent Configuration or Platform. gt_strd5 C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets 737
Severity Code Description Project File Line Suppression State
Error MSB4057 The target "CreateManifestResourceNames" does not exist in the project. gt_strd5 C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets 2630
I found that after the change, some references in the application's project file continued to reference MSBuild 1.5.0. In my case, the gt_strd5.sfproj file contained four references which needed to be updated from 1.5.0 to 1.6.0. See the snippets from the XML below.
Import Project="..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.props" Condition="Exists('..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.props')"
.....
Import Project="..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.targets" Condition="Exists('..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.targets')"
To verify this, I went back a couple times and was able to reproduce both the issue and this solution.
Hope it saves someone else some time.
Best Regards
I was getting this error into PCF control.
Run Developer Command Prompt VS2017/ VS2019
a) Remove white space from your folder like Test%20-%20PCFs (source control generated name) should be TestPCFs
b) Go to pcf project folder from cmd line & run msbuild /t:restore
b) Go to cds project folder from cmd line & run msbuild /t:restore
c) On cds project folder, run msbuild
d) For release deployment run msbuild /p:configuration=Release
For other types of projects
a) Remove white space from your folder name
b) run msbuild /t:restore
c) run msbuild
I've got a Class Library project and a Console project. Inside the Class Library project there's a folder called "ConfigSettings" containing a configuration file that's referenced by the App.config file. Its "Copy to Output Directory" is set to "Copy Always".
The Console project references this Class Library project. When the console project is built, the ConfigSettings folder is created in the correct place along with the external config file. However, every time I Debug the Console project, the external config file is deleted. The ConfigSettings folder however is left untouched. If I mark the file as read-only it is not deleted, and warning appears in Visual Studio's Error List:
Warning Unable to delete file "C:\<path>\<app>\bin\Debug\ConfigSettings\settings.config". Access to the path 'C:\<path>\<app>\bin\Debug\ConfigSettings\settings.config' is denied.
Is there a setting I can change that will prevent VS from removing this file when I Debug the project? I am using Visual Studio 2015.
This might not be the best solution possible, but I found here, if you do a "Clean solution" just before executing your solution, the files will remain.
When I use the option Publish... selecting as target the file system in Visual Studio 2015 it compiles the code, do the XML transformation in the Web.config files and copy the files to the folder I specified.
It does not copy any *.cs file as expected since it is compiled.
Something that I don't understand is why it publishes the Nuget Config file (packages.config), after all, the files needed are already in the bin folder.
I found this question that says how to avoid but not the reason they decided this file would be usable on the server.
Can I stop VS from publishing packages.config?
Anyone know why packages.config end up in the publish folder?
I am trying to create a deployment package in Visual Studio 2013. I have specified that the package should be placed at C:\Deployment\bin\WebSite.zip - the absolutely simplest location. All the project files build but the publish fails with this error:
Transformed Web.config using C:\Services\IdentityServer\Thinktecture.IdentityServer.v2\src\OnPremise\WebSite\Web.Siloed.config into obj\Siloed\TransformWebConfig\transformed\Web.config.
Auto ConnectionString Transformed Areas\Admin\Views\Web.config into obj\Siloed\CSAutoParameterize\transformed\Areas\Admin\Views\Web.config.
Auto ConnectionString Transformed Views\Web.config into obj\Siloed\CSAutoParameterize\transformed\Views\Web.config.
Auto ConnectionString Transformed obj\Siloed\TransformWebConfig\transformed\Web.config into obj\Siloed\CSAutoParameterize\transformed\Web.config.
Copying all files to temporary location below for package/publish:
obj\Siloed\Package\PackageTmp.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets(2584,5): Error : Copying file ..\..\..\Deployment\bin\um.zip to obj\Siloed\Package\PackageTmp\.ebextensions\um.zip failed. Could not find a part of the path '..\..\..\Deployment\bin\um.zip'.
I have no idea where this path '......\Deployment\bin\um.zip' is coming from. I specified that the deployment package should be created at C:\Deployment\bin\WebSite.zip, not um.zip.
So, I checked out C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets(2584,5) and the code looks like this:
<!--Force Copy Of all file to the $(WPPAllFilesInSingleFolder) if needed-->
<CopyPipelineFiles PipelineItems="#(FilesForPackagingFromProject)"
SourceDirectory="$(WebPublishPipelineProjectDirectory)"
TargetDirectory="$(WPPAllFilesInSingleFolder)"
SkipMetadataExcludeTrueItems="True"
UpdateItemSpec="True"
DeleteItemsMarkAsExcludeTrue ="True"
Condition="'#(FilesForPackagingFromProject)' != ''">
<Output TaskParameter="ResultPipelineItems" ItemName="_FilesForPackagingFromProjectTempory"/>
</CopyPipelineFile>
I have tried editing the "PipelineItems" and "SourceDirectory" and have even hardcoded them. But the same message, "Could not find part of the path....", is being displayed every time I run the Publishing. The "Could not find part of the path...." points to the new paths I specified in "PipelineItems" and "SourceDirectory. The .zip file never seems to get created anywhere. I have seached my entire computer for um.zip and WebSite.zip with not luck.
Any help would be greatly appreciated as I am completely out of ideas.
Turns out this um.zip is somehow part of build but it is not getting created. Anyway, I was lucky enough to find a previous deployment package that was generated and I just manually built the new deployment package based off the old one. Deployed fine so I guess that is how I will proceed.
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.