To create a .NET class library from the command line, you can run the script
dotnet new classlib
Do that in a clean folder, and it will create a csproj file that can then be opened in Visual Studio 2017.
However, run the script
dotnet new classlib -lang f#
in a clean folder, and the fsproj file that is subsequently create cannot be opened in Visual Studio 2017. The error message reads
The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks\FSharp.NET.Sdk\Sdk\Sdk.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
I have searched for clarification of this issue, and it appears that there is work ongoing to fix it, but I wondered in the interim if there are any add-ins I can install to get this working immediately.
The latest preview releases of Visual Studio and .NET Core support loading .fsproj projects, apparently.
See this comment on the GitHub issue:
Closing this now, as these projects load with 15.3. The current way to use them:
Download VS 2017 Update 3 Preview 3 (or a further preview if it's released and you're reading this)
Download the latest CLI/SDK from here: https://github.com/dotnet/cli/tree/release/2.0.0#installers-and-binaries
(Yes, the .NET SDK is independent of VS. You will also need this to get .NET Core 2.0 support in VS 2017 Update 3 Previews).
Related
I have a solution which was working with Visual Studio 2015 Community in a machine. That machine was crashed and I can not access the source codes over there any more.
However the source codes were checked into TFS. After I got new machine, I got all latest source codes from TFS.
The issue is that this solution in new machine has a lot of compile errors.
Visual Studio 2015 could restore some of the references. However I have a complain like this -
Clicking button Restore will have this error -
I don't think I have used a version of 1.0.3 of Newtonsoft.Json.dll directly. I deleted the package folder and all project bin and obj folders. The recompile still can not fix it.
What can be done to fix this problem?
Have you also delete the NuGet.Config file in the packages folder? If you did it, Visual Studio will try to do the MSBuild package restore instead of Automatic Package Restore.
By default, the NuGet.Config file instructs NuGet to bypass adding
package binaries to source control. Automatic Package Restore will
honor this as long as you leave this file in place. Note that
NuGet.Config only has an effect when using Visual Studio to integrate
with Team Foundation Server (TFS).
You should also manually remove references in all your projects to the Nuget.targets file. The following article outlines in more details: https://docs.nuget.org/consume/package-restore/migrating-to-automatic-package-restore
If you still can't fix it, try to use the Command-Line Package Restore
We have been using Robert Giesecke's excellent Unmanaged Exports library for a while with our Delphi application. We just upgraded to Visual Studio 2015 and it doesn't seem to be working anymore--I can compile the exact same project in VS2013 and it works fine, can access the functions in the DLL, etc. I recompile in VS2015 (exact same code and project) and I get a build failure on the Unmanaged Exports library as shown below:
Task Parameter:SdkPath=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\ (TaskId:44)
Cannot find lib.exe in 'K:\Visual Studio 2015\Common7\IDE\\..\..\VC\bin'. (TaskId:44)
Done executing task "DllExportAppDomainIsolatedTask" -- FAILED. (TaskId:44)
Done building target "RGieseckeDllExport" in project "BWSITwilio.csproj" -- FAILED.: (TargetId:73)
And as such the library will not export the functions in the DLL for me to access in Delphi. I can stay in VS2013 for a while but something seems amiss with the library in VS2015 (maybe looking in the NETFX 4.6 folder??)
I am open to ideas so I can use VS2015--I was about to uninstall 2013 but have to hold off now.
Thanks in advance for any input or advice--it is really this library that has allowed us to continue to use Delphi since we can access anything in .NET with it!
The release notes for version 1.2.7 (dated 16 August 2015) on Nuget include this:
no longer fails the build when it can't find lib.exe
I suspect you are using an older version and can solve your problem by moving to the latest.
You are probably using a version that was built before VS 2015 was released and I'm sure Robert's latest version now supports VS 2015.
For what it's worth, even if lib.exe still cannot be found that's not going to bother you since you don't need a .lib file to import into Delphi.
I was facing the same issue and was able to solve this by manually copying over some Visual Studio 2013 files into the 2015 folder. I searched for lib.exe on my computer and used Beyond Compare with the two application's program file directories.
Open C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\ in
Explorer, select all files, Copy.
Open C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\ in Explorer, Paste. When prompted to replace, choose Skip.
After doing this I was able to compile my projects that were using RGiesecke.DllExport in Visual Studio 2015 again.
I can't tell you what specific version of 2013 I had installed because I've since uninstalled, but apparently these files are leftover. I'm running MS VS Community 2015 Version 14.0.23107.0.
Not sure if its relevant at all, but the lib.exe I copied from the 2013 bin folder's version reads 12.0.21005.1.
We have SQL CLR dll that we developed quite a long time ago that we have been using. Unfortunately it wasn't ever in our normal daily builds.We are going to be upgrade our sql server from 2008 R2 to 2014. So i opened the project and upgrade it to a visual studio 2013 project (we hadn't opened it for quite some time). I also upgrade the target framework from 3.5 to 4.5.1. Lastly i changed the target sql server version to 2014. I was able to build it locally. I then tried to add it to our TFS build and got the following error:
E:\Builds\8\TRSApps\Dev\Sources\Shared
Objects\Components\FrsSqlCLR\VB Code\FrsSqlCLR.vbproj (76): The
imported project "C:\Program Files
(x86)\MSBuild\12.0\bin\amd64\SqlServer.targets" was not found. Confirm
that the path in the declaration is correct, and that the
file exists on disk.
I was able to resolve the problem. I searched for "SqlServer.targets" locally and found it under the .net 3.5 framework folder (not under 4.x):
C:\Windows\Microsoft.NET\Framework\v3.5
I just copied it to the location it was looking for it above and it fixed the problems which leads me to my questions:
Is TFS looking for SqlServer.targets in the correct location? If so then why isn't SqlServer.targets there?
Is there something i need to install on the build machine?
Why is the file in the 3.5 framework folder and not in the 4.x framework folder
Though i was able to resolve it by copying it from the 3.5 framework folder it seem a kind of hacky solution. I want the details so in the future when we upgrade our tfs server i have all the details.
You need to install Visual Studio 2013 on the build server. Also Sql Server Data Tools for 2013.
Once you have them on the build server it should build as is.
I currently work on a MVC 4.0 project that was upgraded to MVC 5.0 using the official guide.
I use Visual Studio 2012 locally and a publish profile was created for the project.
Locally I call msbuild via the Visual Studio developer command prompt using: msbuild /m /p:Configuration=Dev;DeployOnBuild=true;PublishProfile=Dev my-solution.sln
All projects in the solutions do have a Dev configuration and there is a web.dev.config.
The command line on the server is the same.
So far the difference is that on the server only the visual studio shell is installed (not the full) and we cannot install the full instance of VS2012 on the server.
Also, seeing on the install of TFS on the server, I discovered that only v9.0 target files were installed (Visual Studio 2008). Copying Visual Studio 2012 target files do not fix this problem.
I see 2 solutions so far but searching for a third.
Install full Visual Studio 2012 instance
Update csproj to include a target transformConfigFiles (basically copy and paste the content of the "Microsoft.Web.Publishing.targets" section) or import the file via a declaration inside of the .csproj
Would there be a third solution available?
It is pretty common to install full Visual Studio on your build server. As of VS 2012 you couldn't even run Unit Tests in your build without VS installed.
I'd suggest installing VS and seeing if that fixes the issue.
Is it possible to create XNA games using Visual Studio 2012?
Yes, it's possible with a bit of tweak. Unfortunately, you still have to have VS 2010 installed.
First, install XNA Game Studio 4.0. The easiest way is to install the Windows Phone SDK 7.1 which contains everything required.
Copy the XNA Game Extension from VS 10 to VS 11 by opening a command prompt 'as administrator' and executing the following (may vary if not x64 computer with defaults paths) :
xcopy /e "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft\XNA Game Studio 4.0" "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\XNA Game Studio 4.0"
Run notepad as administrator then open extension.vsixmanifest in the destination directory just created.
Upgrade the Supported product version to match the new version (or duplicate the whole VisualStudio element and change the Version attribute, as #brainslugs83 said in comments):
<SupportedProducts>
<VisualStudio Version="11.0">
<Edition>VSTS</Edition>
<Edition>VSTD</Edition>
<Edition>Pro</Edition>
<Edition>VCSExpress</Edition>
<Edition>VPDExpress</Edition>
</VisualStudio>
</SupportedProducts>
Don't forget to clear/delete your cache in %localappdata%\Microsoft\VisualStudio\12.0\Extensions.
You may have to run the command to tells Visual Studio that new extensions are available. If you see an 'access denied' message, try launching the console as an administrator.
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" /setup
This has been tested for Windows Games, but not WP7 or Xbox games.
[Edit] According Jowsty, this works also for XBox 360 Games.
[Edit for Visual Studio 2013 & Windows 8.1] See here for documentation on installing Windows Phone SDK 7.1 on Windows 8.1. Use VS version number 12.0 in place of 11.0 for all of these steps, and they will still work correctly.
On codeplex was released new XNA Extension for Visual Studio 2012/2013. You can download it from: https://msxna.codeplex.com/releases
I found another issue, for some reason if the extensions are cached in the local AppData folder, the XNA extensions never get loaded.
You need to remove the files extensionSdks.en-US.cache and extensions.en-US.cache from the %LocalAppData%\Microsoft\VisualStudio\11.0\Extensions folder. These files are rebuilt the next time you launch
If you need access to the Visual Studio startup log to debug what's happening, run devenv.exe /log command from the C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE directory (assuming you are on a 64 bit machine). The log file generated is located here:
%AppData%\Microsoft\VisualStudio\11.0\ActivityLog.xml
There seems to be some confusion over how to get this set up for the Express version specifically. Using the Windows Desktop (WD) version of VS Express 2012, I followed the instructions in Steve B's and Rick Martin's answers with the modifications below.
In step 2 rather than copying to "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\XNA Game Studio 4.0", copy to "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\WDExpressExtensions\Microsoft\XNA Game Studio 4.0"
In step 4, after making the changes also add the line <Edition>WDExpress</Edition> (you should be able to see where it makes sense)
In step 5, replace devenv.exe with WDExpress.exe
In Rick Martin's step, replace "%LocalAppData%\Microsoft\VisualStudio\11.0\Extensions" with "%LocalAppData%\Microsoft\WDExpress\11.0\Extensions"
I haven't done a lot of work since then, but I did manage to create a new game project and it seems fine so far.