If I publish with my website with Visual Studio (using FileSystem) it works fine.
Now I'm attempting to do the same from Powershell.
.\MSBuild.exe $sln /p:PublishProfile=MyTestProfile /p:PublishProvider=FileSystem /p:CreatePackageOnPublish=False /p:DeployOnBuild=False /p:VisualStudioVersion=15.0 /v:diag
The above is based upon the output window (of Visual Studio) when I publish (using diagnostic output). Things are copied and pasted to avoid typos.
The problem I have is it never publishes!
I am now shown the following message from Powershell:
Build FAILED.
"C:\Users\me\source\repos\Test03\WebApplication2\WebApplication2.csproj" (default target) (1) ->
C:\Users\me\source\repos\Test03\WebApplication2\WebApplication2.csproj(265,3): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
This issue appears to be well documented here on SO but, I already have VS installed, and this isn't a build server. It's all being done on my one machine... However, if I try to get to the path C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications\Microsoft.WebApplication.targets it doesn't exist. I have C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0\ but within this folder only 1 folder called FileTracker.
This now confuses me more because it works from within Visual Studio, but not within Powershell.
Resolved with
.\MSBuild.exe $sln /p:PublishProfile=MyTestProfile /p:PublishProvider=FileSystem /p:CreatePackageOnPublish=False /p:DeployOnBuild=True /p:AspnetMergePath="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools" /p:VisualStudioVersion=15.0 #/v:diag
You may not have the path for the correct visual studio version. Downloading .NET Core SDK should provide this https://www.microsoft.com/net/download/windows
However, you may need to update to the correct path for the build path (where msbuild.exe exists).
I then had to add /p:AspnetMergePath="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools" manually for reasons I don't understand. I understand that it coudln't find this path, but I didn't understand why it can't find the path when VS could!
Related
I had my project in VS Code's installation directory (C:\Program Files\Microsoft VS Code) because I don't like that any files related to a program placed all over the PC. Then I decided to update VSCode. After the update the folder where my project was, has gone. Are there any ways to restore it? Atleast some of the files? I'm using Windows 7 and don't have any Git accounts.
Windows build-in restoration tool gives me 1 week old folder of my project. I did alot since then. Sometimes you shouldn't work too hard.
I think your best bet is to look if there is any backup of your windows 7 computer to recover your file.
Looks like i got the same problem, when VS Code updates it updates also its installation directory C:\Program Files\Microsoft VS Code, which means any file you create in the installation directory gets deleted, so that's why the Project folder got deleted. It is best to keep your project folders and files in your system for example C:\Projects.. Alternatively you can always use version control ie Git to ensure safety of your code
We have updated the latest visual studio for mac to support our iOS app (Xamarin) in iPad OS 13 which is recently released by Apple. After the update, we are getting the following error in eclipse while detecting the local changes to check-in.
The character 0x007c ('|') is not permitted in server paths '$/<path_to_product>/.vs/<project_name>/xs/project-cache/ProjectName-Debug|iPhone.json'.
It seems to be the file name ("ProjectName-Debug|iPhone.json") with a pipe symbol that is not supported in TFS. But the file is auto-generated by the IDE (Visual studio for mac, Xcode 11) and it contains the following information (ProjectReferences, MetadataReferences, Added files with path, BuildActions, etc...). There are two files that exist with the pipe symbol. One is for the actual device and another one is for the simulator.
ProjectName-Debug|iPhone.json
ProjectName-Debug|iPhoneSimulator.json
Does anyone face this issue? How to resolve it.
Below are the version details.
Mac OS 10.14.6
Eclipse 4.7.3
Xcode 11
Visual Studio for Mac 8.2.6
Thanks in advance.
Quick fix: Currently we are manually deleting those files while committing the changes. Again it will regenerate automatically.
For local workspace, you should use .tfignore file to ignore files. Such as
# Ignore the NuGet packages folder in the root of the repository.
# If needed, prefix 'packages' with additional folder names if it's
# not in the same folder as .tfignore.
packages
# include package target files which may be required for msbuild,
# again prefixing the folder name as needed.
!packages/*.targets
As for how to generate this file, please refer my answer in this question: Visual Studio 2015 TFS .tfignore file
Note: This .tfignore file will not affect with those files already in source control.
Manually delete those files while committing the changes. Then make sure your .tfignore files has checked in source control. Next time when those files auto generated will be exclude by source control in the pending changes.
I ran Protobuild.exe, but no one has mentioned where it outputs to. Does anyone here know where the default folder is suppose to be at?
Running Protobuild.exe generates the Visual Studio projects and solutions for every platform. The solutions are in the root directory, i.e. along Protobuild.exe.
Note that Protobuild does not build the framework - you have to open the solution and build it in Visual Studio (which generates its output in MonoGame.Framework\bin subdirectory).
I'm trying to get MSTest.exe to run, and it seems like testcontainer isn't being read properly; while my tests all run successfully in all config environments within Visual Studio.
the command I'm using is:
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe" /nologo /usestderr /testSettings:"C:\temp\MyProject\Sources\MyProject\Local.testsettings" /searchpathroot:"C:\temp\MyProject\Binaries" /resultsfileroot:"C:\temp\MyProject\TestResults" /testcontainer:"C:\temp\MyProject\Binaries\MyProject.Services.Server.UnitTests.dll"
The project references within testcontainer project look like this:
<ItemGroup>
<ProjectReference Include="..\..\Services\MyProject.Services.Server\MyProject.Services.Server.csproj">
<Project>{92EC1999-CC0C-47DD-A4D6-17C3B1233C50}</Project>
<Name>MyProject.Services.Server</Name>
</ProjectReference>
<ProjectReference Include="..\..\SvcConfiguration\MyProject.ServiceConfiguration.Interfaces\MyProject.ServiceConfiguration.Interfaces.csproj">
<Project>{8E2E7BA9-75DB-458E-A184-AC1030EAD581}</Project>
<Name>MyProject.ServiceConfiguration.Interfaces</Name>
</ProjectReference>
<ProjectReference Include="..\..\SvcConfiguration\MyProject.ServiceConfiguration.Services\MyProject.ServiceConfiguration.Services.csproj">
<Project>{39514766-23A8-45DB-96EA-B6B4D9C8B086}</Project>
<Name>MyProject.ServiceConfiguration.Services</Name>
</ProjectReference>
</ItemGroup>
Neither the ServiceConfiguration.Interfaces nor the ServiceConfiguration.Services DLL is placed into the Out folder in TestResults.
The project GUIDs do match between the references and the referenced projects.
Is there something that I'm missing in the command line?
mstest.exe will not coy all referenced dll's.
See a blog post on this at https://web.archive.org/web/20111221110459/http://www.dotnetthoughts.net/2011/11/22/mstest-exe-does-not-deploy-all-items/
You can specify exactly what files are copied to the test directory using a test settings file. You can create multiple test settings files in Visual Studio, so you can have one for running from VS, another for running from MSTest, another for server CI builds, and so on. See here for more information: Create Test Settings to Run Automated Tests from Visual Studio
Use the /testsettings:<filename> option to specify it on the command line.
What seems to confuse people at first is that, by default, MSTest's "current directory" is not the MSTest launch directory, but the Out folder of the test results.
As mentioned previously, MSTest does not correctly infer all used assemblies, if you don't have a direct reference, it will not copy the assembly. That said, Visual Studio has similar behaviour in its build too, so a lot of people work around this by adding bogus code references - a terrible solution - I don't recommend it.
However, native DLLs are even more problematic, and I have found that explicitly copying them in the test configuration (test settings) works for them, just as for managed assemblies.
Whether it goes to Out or the build area depends on different factors, however, for the situations where it still doesn't work, you can use a DeploymentItem "hack", or, tweak your runsettings file.
Try looking at this answer: https://stackoverflow.com/a/33344573/2537017
I have just installed Microsoft Robotics Studio 2008 R2, and I must admit that I'm shocked to discover how paths are handled.
First of the studio wants to install itself into my personal profile (this is on Vista):
C:\Users\MyUserName\Microsoft Robotics Dev Studio 2008 R2
I assume this is because during development I have to write files to the robotics studio folder making C:\Program Files a no go.
Then when I create a new robotics project a lot of absolute paths pointing to the robotics studio is added to the project. If I check my project into source control and another developer checks it out onto his machine the absolute paths will not resolve and the project will not compile.
Also, since all services are collected into a single folder in the robotics studio folder developing multiple independent services on a single computer appears to be at least confusing.
Do you have any good strategies for handling this mess?
I have now figured out a way to change a Microsoft Robotics DSS Service visual studio project into something that you can compile and run in you own source tree independent of the installation path of the robotics studio. Here is a description of what you need to do to modify the project:
Add the robotics studio bin path to you PATH environment variable to be able to execute dssproxy.exe without supplying a full path. I have installed robotics studio into the program files folder to avoid accidentially writing files to the robotics studio folders.
Open the Properties page for the project and select the Build tab. In the Output section change the Output path to Debug\bin. For .NET projects it is customary to compile into folders bin\Debug and bin\Release but the robotics hosting service expects to live in a folder named bin and will store data in the folder above the bin folder.
Go to the Signing tab and select a new key in the Choose a strong name key file box. You can either generate your own key at that point or use the sn.exe utility to generate a new key. Or if you have your own policy for creating keys follow that. The sn.exe utility can be found in the tools folder of robotics studio.
In the Build Events tab edit Post-build event command line:
dssproxy.exe /dll:"$(TargetPath)" /proxyprojectpath:"$(ProjectDir)Proxy" /keyfile:"$(SolutionDir)Key.snk" $(ProxyDelaySign) $(CompactFrameworkProxyGen) /binpath:"." #(ReferencePath->'/referencepath:"%(RootDir)%(Directory) "', ' ')
Pay attention to the argument to /keyfile. Enter an expression that locates the strong name key file created in the previous step.
Copy the files DssHost.exe and DssHost.exe.config (or DssHost32.exe and DssHost32.exe.config for the 32 bit hosting service) from the robotics studio bin folder into the project folder and add these files to the project. Set the Build Action to Content and Copy to Output Directory to Copy if newer. Do the same for the manifest file for your service. Actually, the manifest file doesn't have to be in the same folder as the service, but copying it to the output folder enables you to do XCOPY deployment.
In the Debug tab change the Start external program to the DssHost.exe in the output folder of your project. You will have to build the project once to copy the file to the output folder. Clear the Working directory. Set the Command line arguments to
/p:50000 /t:50001 /m:DSSService1.manifest.xml
Change the manifest file name to the proper name in your project. You can modify the port numbers used either here or in the DssHost.exe.config file. If you are running in a protected Windows environment (UAC) you will have to use the httpreserve command to give yourself access to a particular port. You have to run this command as administrator.
Debug settings are not stored in the project file and each developer will have to create personal settings.
You should also update the Release configuration accordingly.
Since I was only interested in the CCR of MS Robotics, I just add these assemblies as a reference to any project I use it with and just be done with it.
This works without any problems. So if you are also only interested in the CCR and DSS part of the studio then this could be your solution
Reinier
we see this problem a lot. The absolute easiest solution is to specify the install directory when installing robotics studio to be "C:\program files\microsoft robotics studio". That way moving code between machines, checking out of source control, etc becomes a lot less problematic.
The other option is to use dssprojectmigration, which is included with RDS. Just run dssprojectmigration against your project directory, and it will correct all the hardcoded paths.