When I load an existing Visual Studio project in Visual Studio Code, I get errors because the project files refer to variables ("properties"?) that are not set properly by Visual Studio Code.
For example $(VisualStudioVersion) seems to be set to 10.0, so I get errors like this
Microsoft.Build.Exceptions.InvalidProjectFileException: The imported
project "C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v10.0\TypeScript\Microsoft.TypeScript.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
c:\SvnWork\HM.Plan.ProductPlan\HM.Plan.ProductPlan.Web\HM.Plan.ProductPlan.Web.csproj
From project content like this
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props" Condition="'$(ExpectedTypeScriptIsInstalled)'=='true'" />
How do I set variables like $(VisualStudioVersion) in Visual Studio Code?
I've fixed the similar issue with Microsoft.WebApplication.targets by adding the explicit override from 10.0 to 14.0
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == '10.0'">14.0</VisualStudioVersion>
However, this is definitely a matter of change in future VS code versions. Why 10.0?
Related
I have DevExpress XtraReports v18.1.6 version and PostgreSQL 4 v3.3. Visual studio 2017 v15.3.3 and Windows 7.
Here is scenario: In my project, I have some reports writen in devexpress v17.2. I could not run those reports, because I could not download exactly that version 17.2, I install new 18.1.6. Then in Visual studio main menu "DevExpress" I click on "Project converter to 18.1.." and that action replace my old dlls v17.2 with new 18.1. After that I could run reports (see it in designer).
But problem is with databse connection. I created connection string with "XpoProvider=Postgres".
Every time when I want to get data in report, or rebuild result shema, or manage queries I get error:
Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.0,...
I have that reference, exactly that version. Also I tried with new versions of threading.tasks but unsuccessfully.
My version of Npgsql.dll was 2.2.7, I tried with 3.2.5 (read from some devexpres documentations). Also tried with new 4.0.3.
Did anyone have a similar problem?
we had the same issue when using the DevExpress (18.1) Report Designer with Visual Studio 2017.
I know this might not be an ideal or the best solution but at least it worked for us:
I used ProcMon to determine where it was looking for that specific File, for me it turned out to be C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\hhfnlhs1.kna
I downloaded the NuGet Package for System.Threading.Tasks.Extensions from NuGet (https://www.nuget.org/packages/System.Threading.Tasks.Extensions/)
I unzipped the Package and stored the DLL at that path from step 1
I had to active "loadFromRemoteSources" in my machine-config (see https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/dd409252(v=vs.100))
I had to put another DLL from NuGet (https://www.nuget.org/packages/System.Runtime.CompilerServices.Unsafe/4.5.2) into that folder from step 1
That's it - now I can access the DB again.
I'm using Visual Studio for my Unity project. (Unity is using mono framework, NOT .net). I'm using a database so I have to use System.Data.dll in the project which i'm keeping in Assets/Plugins folder:
As you can see Visual Studio has problems seeing System.Data library. So I'm hardcoding:
And some more red lines:
Surprisingly, I have no errors in Unity and the code is actually working:
I also have this annoying yellow icon in VS:
Can you help me in forcing Visual Studio to see System.Data library please?
The System.Data.dll, System.MySql.dll and System.Drawing.dll should all placed in the Assets folder not in the Assets/Plugin folder. Making these changes get ride of the error.
EDIT:
Adding System.Data.dll to the Assets folder should work but is failing silently. Digging deeper into this, I got this error:
The primary reference "System.Data" could not be resolved because it
has a higher version "2.0.5.0" than exists in the current target
framework. The version found in the current target framework is
"2.0.0.0".
So, the System.Data.dll version is different from your target framework and that is the problem. You need another version of System.Data.dll that is the-same version of your target framework(2.0.0.0).
You can get a compatible version(2.0.0.0) from:
C:\Program Files (x86)\Reference
Assemblies\Microsoft\Framework\.NETFramework\v3.5\Profile\Unity Subset
v3.5
When adding the media services nuget package, VS 2015 is giving me errors about having no working folder mapping, then rolls back.
Here is an example of the message:
There is no working folder mapping for C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\lib\net45.
When I open the same solution from VS 2013, it works as expected.
Does anyone know how to resolve the error is VS 2015, or perhaps why it doesn't work there but does work in VS 2013?
(In VS 2015, I opened the solution by browsing to the sln file locally - not by retrieving the solution from source control.)
This is a known bug: https://github.com/NuGet/Home/issues/1004 Use Visual Studio 2013 for now. In the rush to get it out, Microsoft released a product that was not ready, even though technically this is a NuGet issue.
Not a long term solution, but I unbound from TFS, added the packages I needed, then rebound.
Try to unbound the solution and projects in TFS before updating the nuget packages.
To unbound try this
You should be able to avoid the error if you unbound from TFS. To unbound, go to File->Source Control->Advance->Change Source Control. Select the project and click on the Unbound button\link at top.
I'm working on a Visual Studio extension which will contain some workflows for database and code generation. One assembly named MyActivities contains some implementations of NativeActivity which are then used in XAML workflows like this:
<Sequence xmlns:my="clr-namespace:MyActivities;assembly=MyActivities">
<my:MyActivity CsdlInput="[Csdl]" SsdlOutput="[Ssdl]"/>
...
This is very similar to what the Entity Database Generation Power Pack does for Visual Studio 2010. However, our extension will be for VS2012.
Now I need a way to link this assembly to Visual Studio, so that it's available when the workflow executes. I tried creating a VSIX extension and adding the assembly as an Asset. I tried different Asset types, for example Assembly or MefComponent, but none worked. Visual Studio keeps telling me:
`Cannot create unknown type '{clr-namespace:MyActivities;assembly=MyActivities}MyActivity'.
What kind of Asset do I need to create a simple VSIX extension that installs my assembly so Visual Studio can use it?
I was able to achieve what I want:
In the project that uses the activity workflow, just add a reference to the assembly that contains the activity code (MyActivities in my case).
So maybe it's not necessary (or not possible) to create a VSIX extension that does what I want. But adding the reference is fine, too.
I've got a project that uses Autofac, and the WebAPI integration
We run FxCop over our solution, and on opening autofac, I get the following:
The following indirectly-referenced assembly could not be found. This
assembly is not required for analysis, however, without it, analysis
results could be incomplete. This assemble was referenced by
Autofac.dll
System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes
This causes the following error on our CI server:
FxCop return code (516): PROJECT_LOAD_ERROR ASSEMBLY_REFERENCES_ERROR
Is there a way to tell FxCop to ignore this?
Had the same issue with AutoMapper 3.1.0 on our project. The real problem is an old version of FxCop. The last official release was FxCop 10.0, but new versions of FxCop have been bundled with Visual Studio since 2012.
I just replaced the FxCop 10.0 with the version that can be found in:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Team Tools\Static Analysis Tools\FxCop
or
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop
and the problem was solved.
This is a common FxCop thing when running with Portable Class Libraries. It's not Autofac; you just happen to see it because Autofac is the only PCL you're using. In my experience, this error doesn't seem to happen if you're building on a Windows 8 machine, but on Windows 7 or Server 2008R2 I see this a lot.
It's not a bug, and no, you won't find 2.0.5.0 on your machine. That version is actually for Silverlight and runtime .NET "stuff" handles redirection to the right assembly version. Unfortunately, FxCop is less cooperative.
I see the same thing in my build and solved it using the suggestions from questions like this: How to fix FxCop error code 512?
You must add a reference to the assembly's directory in the FxCop project file. For instance:
<Targets>
<AssemblyReferenceDirectories>
<Directory>C:/Windows/Microsoft.NET/assembly/GAC_MSIL/Microsoft.Web.Infrastructure/v4.0_1.0.0.0__31bf3856ad364e35/</Directory>
<Directory>C:/Windows/Microsoft.NET/assembly/GAC_MSIL/System.Web.Mvc/v4.0_3.0.0.0__31bf3856ad364e35/</Directory>
</AssemblyReferenceDirectories>
Workaround for this issue is to copy the missing System.Core.dll to the project output directory. I made this as a postbuild event to copy System.Core.dll from a shared folder to project\bin directory.
You can get the copy of System.Core.dll from the Silverlight SDK 2 installation.
Now fxcop runs successfully without any issues. Note that I was using Fxcop integrator for Visual Studio 2010.