I made a new .NET Class Library solution if TFS, and added a bunch of preexisting classes that were developed for a windows forms application. Basically just dumped the old folder in. The forms app worked fine and the folders in bin were expectedly barren, apart from the exe and the required nuget references. The dll build however copies over libraries all the way from Microsoft.Win32.Primitives.dll, to System.Xml.XPath.XDocument.dll for no apparent reason. I have removed unused references with ReSharper and commented out unnecessary using statements. No difference whatsoever. I don't think it's a problem from the deployment perspective, it's just annoying to have so many files copied over each build. Could it be that the initial presence of Forms just poisoned the new project forever? Any help whatsoever would be much appreciated.
Prevent Visual studio 2017 from copying almost 100 unnecessary system
dlls to output folder for dll project
Please check if your VS2017 is very old and also check if the framework version of your project targets to 4.6 or 4.7.1.
If so, there is an known issue about this issue.
This is a .net standard 2.0/net 4.6/4.7.1 issue which was improved in 4.7.2. You can check this similar issue.
Suggestion
1) you should first update your VS2017 in case some updates fix it.
2) change the framework version of your project to net framework 4.7.2.(if you do not have net frameowork 4.7.2, you should install it in the VS Installer)
Related
I am attempting to convert the Microsoft.Health C# class library that is installed as part of the HealthVault SDK, using instructions provided here. After following these instructions, I get the following error when attempting to load the project into Visual Studio 2013.
"The project is targeting frameworks hat are either not installed or
are included as part of future updates to Visual Studio. See
http://go.microsoft.com/fwlink/?LinkId=287985"
Visiting the link takes me to .NET SDKs and Downloads. Once there, I have no clue on what needs to be done.
I do realize that one will have to leverage the Portable Class Library Contrib project to fill in some missing bits, especially code related to System.Security. This, I will deal with later.
Any one run into a similar problem?
Maybe so late but for those who have the same problem.
I had the same error in a project which was working perfect before updating VS2013 and finally after 3 hours looking for the source of the error I found that the error is about TargetFrameworkProfile.
In my case I sloved it like so:
Right click in the unloaded project in your solution and click Edit.
Find the TargetFrameworkProfile tag and set it as below:
<TargetFrameworkProfile>Profile78</TargetFrameworkProfile>
At a guess, this is because you need to specify the TargetFrameworkVersion and TargetFrameworkProfile properties in the project file. Compare the .csproj you are trying to create to a newly created PCL project file, and make sure that everything that's not specific to your project matches.
I ran into the same issue and got it resolved by installing the latest Visual Studio Update
We have a few projects within our CI environment which have been building successfully. Over the weekend, our IT team installed Azure SDK udpates, and since then, our project to not build anymore (even though they don't reference Azure).
The way we are building projects is
<MSBuild Condition="'$(BuildProject)' != ''" Projects="#(Projects)"
Properties="Platform=$(Platform);Configuration=$(Configuration);OutDir=$(TempProjectFilesPublish)\bin\;WebProjectOutputDir=$(TempProjectFilesPublish)"
Targets="Build"
ContinueOnError="false">
where #(Projects) is a reference to the Solution folder.
<Projects Include="$(BuildProject)"/>
The issue is around resolving project references. Nothing has changed over the weekend. The project references are correct, the csproj file has the appropriate values, no new projects or code changes have been made which is leading me to think something has been disrupted.
Wondering if anyone might know of any changes to MSBuild that would affect this?
This issue ended up being a bug in Azure SDK 2.3 with a conflict to Newtonsoft.JSON dll.
The SDK installs a 4.5 build version into the GAC, which is overriding any Newtonsoft references in projects to 4.0.
https://connect.microsoft.com/VisualStudio/feedback/details/850425/windows-azure-vs-tools-breaking-msbuild-for-web-projects
Microsoft have stated this will be fixed in 2.4.
I experience the same problem with Azure SDK v2.9. I've fixed the build for the moment by uninstalling "Microsoft Azure Library for .NET v2.9".
P.S.: Unfortunately, the link provided in the answer by mickyjtwin no longer works.
P.P.S.: The following question seems to be related:
Visual Studio keeps overwriting NewtonSoft.Json.DLL with an older version
I had created (modified an existing project) a server side plugin that has been working (on TFS 2012) for quite awhile. When I upgraded the server to 2013, I copied the .dlls over to the same folder within the 2013 directory structure (Application Tier\Web Services\bin\Plugins), but it no longer works.
I installed remote debugging, attached my debugger to the w3wp.exe process (like here: Problem with Custom TFS Web Service Plugin), and performed check-ins. I'm pretty sure everything was in place because the first time I tried Visual Studio reported that symbols weren't loaded, but after copying up the .pdbs it looked
good. The ProcessEvent method never hit.
I can't find any new documentation on this stuff, guess this is just desperation, does anyone know what to do to make my plugin load?
You need to recompile the plugin against the 2013 assemblies (there are tricks using binding redirects, but if you have the sources, please just recompile). And you need to set the .NET framework version to .NET 4.5 in order for the solution to compile (the TFS 2013 binaries target that framework version, so your plugin must target either 4.5 or higher in order to reference these assemblies).
After installing Slow Cheeath (v. 2.5.10.3) to two projects in my solution, I am receiving the following error:
"The "SlowCheetah.Xdt.TransformXml" task could not be loaded from the assembly C:\Users
\User\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.2\SlowCheetah.Xdt.dll. Could
not load file or assembly 'file:///C:\Users\User\AppData\Local\Microsoft\MSBuild
\SlowCheetah\v2.5.10.2\SlowCheetah.Xdt.dll' or one of its dependencies. The system cannot
find the file specified. Confirm that the <UsingTask> 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. ISA.IMPD.FalseAlarm.Web.Portal"
I have removed both projects in their entirety (along with Slow Cheetah), re-installed both projects (along with Slow Cheetah), and Rebuilt the solution to no avail. Can anyone help with this type of error?
In my case the error occured while compiling a web project. The folder
%userprofile%\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.2
was empty. All the SlowCheetah components were in SlowCheetah\v1 folder instead. I've copied all files from V1 folder to v2.5.10.2 and everything compiled and transformed fine. To make non web projects compile, I also had to delete V1 folder as suggested by Whoever in this thread.
This was a brand new installation of the SlowCheetah Extension and I did not expect the v1 folder to exist at all. I believe this was a bug in the extension installation for Visual Studio 2012.
delete
AppData\Local\Microsoft\MSBuild\SlowCheetah\v1
I seem to have found to solution to this problem.
Here's what I did:
You need to close Visual Studio, then navigate to:
C:\Users\username\AppData\Local\Microsoft\VisualStudio\11.0\Extensions
Delete the cache file that has the latest date and time
Open Visual Studio and remove Slow Cheetah from the Solution level
Re-install Slow Cheetah from the solution level to the desired projects.
This was failing on our build server, so I changed the revision number from:
<sc-MSBuildLibPathLocal Condition=" '$(sc-MSBuildLibPathLocal)'=='' ">$(LocalAppData)\Microsoft\MSBuild\SlowCheetah\v2.5.10.2\</sc-MSBuildLibPathLocal>
To:
<sc-MSBuildLibPathLocal Condition=" '$(sc-MSBuildLibPathLocal)'=='' ">$(LocalAppData)\Microsoft\MSBuild\SlowCheetah\v2.5.10.3\</sc-MSBuildLibPathLocal>
Why it was pointed to v2.5.10.2 is a mystery, but I'm definitely using v2.5.10.3! Looks like the nuget package itself has the bug in it.
I resolved it like this:
Uninstall slowcheetah => Tools>Extensions and Updates
click OK when VS asks you to restart VS.
in "C:\Users\AppData\Local\Microsoft\MSBuild\SlowCheetah" remove the 'v1' folder (which windows automatically creates when restarting your VS) (here be dragons..)
reïnstall slowcheetah (see step 1) => a new folder v2.5.10.2 will be created.
Again, click OK when he asks to restart
Build your solution
Regards,
Peter
This problem went away for me after using the preview transformation feature in the context menu. Originally suggested here.
FYI this was on VS 2010 Premium.
Having multiple versions can lead to conflicts.
In my case I have installed both Microsoft.VisualStudio.SlowCheetah by Microsoft and SlowCheetah by Sayed Ibrahim Hashimi. After uninstalling the package from Microsoft everything went well.
I have deleted the old files in C:\Users\\AppData\Local\Microsoft\MSBuild\SlowCheetah\v1. I also needed to upgrade Visual Studio 2012 to update 4 to make it work.
I was able to fix this issue by doing the following:
Uninstalling the SlowCheetah extension from the TOOLS > Extensions and Updates... menu
Closing Visual Studio
Deleting all files in the "C:\Users\username\AppData\Local\Microsoft\VisualStudio\11.0\Extensions" folder
Opening Visual Studio
Reinstalling SlowCheetah from the TOOLS > Extensions and Updates... menu (which requires a Visual Studio restart)
This is using Visual Studio 2012 Premium with Update 4 and SlowCheetah version 2.5.10.
If you're getting this error on a TFS Build Server (in my case TFS Express 2013) then you will need to copy over the files from your local machine
C:\Users\SWEAVER\AppData\local\Microsoft\MSBuild\SlowCheetah
on your machine to whichever user your TFS build is running under
C:\users\TFSBuild\AppData\Local\Microsoft\MSBuild\SlowCheetah
Please note AppData is a hidden directory that you may not see, but just type the name and hit enter and it will come up.
I'm using VS2013 so I didn't copy v1 (I think v1 is for VS2012).
The original TFS error I got was :
C:\Builds\1\www.XXXXX.com\RRStore - XXXXX
Silverlight\Sources\RRStore.AdminConsole\Properties\SlowCheetah\SlowCheetah.Transforms.targets
(150): The "SlowCheetah.Xdt.TransformXml" task could not be loaded
from the assembly
C:\Users\TFSBuild\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.2\SlowCheetah.Xdt.dll.
Could not load file or assembly
'file:///C:\Users\TFSBuild\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.2\SlowCheetah.Xdt.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.
Fortunately this error told me exactly where to place the files.
I had the same problem in Visual Studio 2013. Just install SlowCheetah NuGet package:
https://www.nuget.org/packages/SlowCheetah
They've released a new version which brings the installation procedure up to date:
https://blogs.msdn.microsoft.com/visualstudio/2017/05/25/whats-new-and-improved-with-the-slowcheetah-extension/
Tired of having to install your NuGet packages manually to get
SlowCheetah to work? We’ve added automatic NuGet installation to help
streamline your process. All you need to install is the latest
extension and SlowCheetah will take care of the rest. When you use
SlowCheetah for the first time in a project, it will prompt you to
install or update NuGet packages. Agree and you’re ready to go!
Close Visual Studio
Install the VISX extension
Open your project.
This version detects if you already have it installed and offers to upgrade.
I would recommend checking in to source control and then doing a compare of your .csproj file to see what changes it made.
I am trying to deploy a Visual C++ application (developed with Microsoft Visual Studio 2008) using a Setup and Deployment Project. After installation, users on some target computers get the following error message after launching the application executable: “This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem.” Another user after installation could run the application properly. I cannot find the root cause of this problem, despite spending several hours on the Visual Studio help files and online forums (most postings date back to 2006). Does anyone at Stack Overflow have a suggestion? Thanks in advance. Additional details appear below.
The application uses FLTK 1.1.9 for a GUI library, as well as some Boost 1.39 libraries (regex, lexical_cast, date_time, math).
I made sure I am trying to deploy the release version (not the debug version) of the application. The Runtime library in the Code Generation settings is Multi-threaded DLL (/MD).
The dependency walker of myapp.exe lists the following DLLs: wsock32.dll, comctl32.dll, kernel32.dll, user32.dll, gdi32.dll, shell32.dll, ole32.dll, mvcp90.dll, msvcr90.dll.
In the Setup and Deployment Project, I add the following DLLs to the File System on Target Machine: fltkdlld.dll, and a folder named Microsoft.VC90.CRT with msvcm90.dll, msvcp90.dll, mcvcr90.dll and Microsoft.VC90.CRT.manifest.
The installation process on the target computers getting the error message requires having the .Net Framework 3.5 installed first.
Any suggestion? Thanks in advance!
Add the Visual C++ Redistributable to your Deployment project and be sure to run Setup.exe instead of the MSI when installing. This will invoke the VCRedist bootstrapper to ensure your PC has those pieces before installing your app.
Dependency Walker only shows static (link time) dependencies - it cannot possibly know about dynamic dependencies such as COM objects.
I had a similar problem after the ATL security updates last year. My app needed a later version of the C++ runtime libraries than the deployment project included.
Try running Windows Update on the target machines after installation, or download and install the latest (28 July 2009) C++ redistributable package directly.
http://support.microsoft.com/?kbid=973551
That solved the problem for me. I haven't fixed the deployment project yet though.