I am using Visual Studio 2015 (Pre), Framework 4.5.2
I have the folowing project structure
StorageProject
nuget package Microsoft.WidowsAzure.Storage is installed
This Nuget package has (among others) dependencies on Microsoft.Data.OData, wich is also installed
AnotherProject
Has a refernce on StorageProject
Does not have any nuget package or other refernces (except default references on the framework)
Here is the list of the packages installed in StorageProject
WindowsAzure.Storage 4.3.0
Microsoft.WindowsAzure.ConfigurationManager 3.1.0
System.Spatial 4.3.0
Microsoft.Data.Edm 5.6.4
Microsoft.Data.OData 5.6.4
Microsoft.Data.Services.Client 5.6.4
These are all dependencies of WindowsAzure.Storage, latest versions.
There is no other version of these packages installed anywhere on the solution.
I will focus on Microsoft.Data.OData, but the same problem occurs with Microsoft.Data.Edm and Microsoft.Data.Services.Client 5.6.4
When building StorageProject, the correct version of these dll (5.6.4) ends up in the bin folder of the project.
But when building AnotherProject, the bin folder contains version 5.6.2 of the dll.
Now I passed all day trying to figure out where these dlls come from.
There is a version 5.0.0.0 in the GAC, wich I cannot uninstall. (gacutil yields it is used by something).
I did a file search on C:\ to find that the only place where this version of the dll is (beside the bin folder of my project) is in C:\Program Files (x86)\Microsoft WCF Data Services\5.6.2. If I delete (move) this folder, my project builds "normally" and everything is fine. In fact, in this case OData is not in the bin folder at all. And as far as I am concerned, that's ok this way.
Now the real question(s) :
Why is it the version from Microsoft WCF Data Services that ends up in the bin, instead of the version actually installed in the referenced project?
Where does Microsoft WCF Data Services comes from ? I don't remember installing it at all, maybe it comes with a version on Visual Studio? (I have 2012, 2013 and 2015 installed)
Can I uninstall it? I don't see it in Windows' control panel.
•Why is it the version from Microsoft WCF Data Services that ends up in the bin, instead of the version actually installed in the referenced project?
This could be due to the fact that the storage client does not depend on a specific version of the Data Service Client. Since Specific Version is set to false, the GAC will be searched first during compilation, any version will be considered "acceptable", and no other version will be exported.
•Where does Microsoft WCF Data Services comes from ? I don't remember installing it at all, maybe it comes with a version on Visual Studio? (I have 2012, 2013 and 2015 installed)
It could be installed due to a variety of reasons. The Azure SDK contains this as well. So if you ever installed the Azure SDK, it could have come with that.
•Can I uninstall it? I don't see it in Windows' control panel.
Looks like this is only possible by uninstalling the MSI package that installed the assembly via Add/Remove programs. For that, you would have to again figure out which installation brought this assembly with it and check whether that is needed or not.
Related
I am trying to build a dotnet core web app on a build server that has MsBuild, but not Visual Studio, installed. I cannot get around the message error MSB4236: The SDK 'Microsoft.NET.Sdk.Web' specified could not be found.
The command dotnet --info shows Microsoft.NETCore.App 3.1.0 installed, just as on my development machine where the project builds. The contents of C:\Program Files\dotnet\sdk\3.1.100 appear to match between the two machines. Global.json points to the 3.1.0 version.
Is Microsoft.NET.Sdk.Web a separately-installed thing? I see what look like separate packages, now deprecated, on NuGet, and I'm guessing this is now baked into the base .NET SDK?
Where should I be looking for differences to try to find the missing pieces?
Solved the problem by (1) running vs-buildtools installer to put some additional pieces in place, and (2) adding some NuGet packages for web component.
Is it possible to upgrade the Microsoft.CodeAnalysis reference to something like version 1.3.x and still get the analyzer to load in VS2015?
I've got this setup working in my analyzer development environment so there seems to be some way for VS2015 to run analyzers that depend on Microsoft.CodeAnalyzer 1.3.1 for example.
However when I install the analyzer off the VSIX package to my office PC that doesn't have the VS SDKs installed VS complaisn that the extension "does not contain any analyzers". Now that I downgraded the Microsoft.CodeAnalysis references back to 1.0.0 everything works again.
How is targeting multiple VS versions supposed to work in the future in case each VS requires a reference to the same Microsoft.CodeAnalysis assembly that it uses internally?
The 1.N packages work with Update N of Visual Studio, but there is no way to use 1.3 packages with something less than Update 3.
I previously had only SQL version 12 of both (localdb)\ProjectsV12 and (localdb)\MSSQLLocalDB
This is when I had VS 2015 Update 1 installed, along with SSDT tools(for database projects).
I installed Update 2 and now have:
Notice MSSQLLocalDB is still on the old version.
However, a coworker did a fresh install of VS 2015 and has this:
So they are on a newer version of MSSQLLocalDB, and I am on an older. Even though we are both up to Update 2 of Visual Studio.
I had hoped to move to using the version independent name of MSSQLLocalDB. The problem is, this won't work if everyone is on different versions, because I have the build setup to deploy the Database project to localdb, which requires use of SqlPackage, which is version specific:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\120\SqlPackage.exe
I want to understand where and how MSSQLLocalDB gets installed and updated. I'm pretty sure ProjectsV12/13 comes as part of the Visual Studio install.
What installs MSSQLLocalDB, and what updates it?
Duplicate
The proposed duplicate just describes the MSSQLLocalDB as "the SQL Server 2014 LocalDB default instance name". This doesn't say anything about what it is installed as part of, or what updates it. Thanks
There are several related questions here.
What version of SqlPackage.exe to use
SqlPackage and all the SSDT tools are backwards compatible to SQL Server 2005. You should use the following 130 version to run against any database. It has the latest bug fixes and can target all publicly released SQL versions:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130\SqlPackage.exe
This will work against MSSQLLocalDB regardless of whether it is v13.0 or v12.0.
LocalDB Instances - how are they created and managed
MSSqlLocalDB is a default instance always installed on the machine. The ProjectsV12 and ProjectsV13 are created by SSDT using the LocalDB API. The purpose of having separate versions is
To keep isolation from the default instance, since this is used by many other processes & project types
To ensure we have a known version (e.g v13) so that we can reliably publish with the latest SQL Server features to it
Why do you and your coworker have different instances
Your coworker installed VS2015 Update 2 directly, with no previous version installed. This means the older code never created a ProjectsV12 instance on their machine.
What installs MSSQLLocalDB, and what updates it
If you've previously installed LocalDB v12.0 (by using SSDT as part of VS2015 RTM or Update 1), it will have connected to & started MSSqlLocalDB. Hence, it created the instance as version 12.0.
If you never started this instance before (e.g. your colleague's example), then when first started it will be run from the v13.0 LocalDB and hence get v13.0 as the instance version.
As far as I am aware, it will not be upgraded from v12.0 to v13.0 at any point.
Does MSSqlLocalDB version matter?
This depends. For most testing & ad hoc development this really doesn't matter.
If you care about version, for example if you're creating mdf of .bak files for application use, then you should use the LocalDB APIs to create a specific SQL version. Just download the relevant versioned MSI, install, & use the -version flag during instance creation via the API or command line. This may be the case too if you're using formal SSDT Publish operation instead of F5 deploy, though using the "Allow Incompatible Platform" option should work fine to work around.
Downloaded and ran SQLite setup.
Added dll reference to my project
In Server Explorer, added new connection, clicked 'Change' for data source and SQLite was one of the options.
Connected and used my tables.
Then...VS 2010 crashed.
When I reloaded my project, my connection wasn't in Server explorer, so tried to add it again.
SQLite was not in the list of options.
Re-ran SQLite setup, deleted/re-added reference, restarted project...still no SQLite in the list.
How can I get SQLite connected in Server Explorer???
This is an old question but for someone, like me, who finds this before there is a newer answer:
missing SQLite data provider in VS 2013
Basically for the latest versions of SQLite you can download an installer that includes the components
http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
Choose the right setup for you, for me was:
Setups for 32-bit Windows (.NET Framework 4.5.1)
sqlite-netFx451-setup-bundle-x86-2013-1.0.94.0.exe
I have Windows 7 x64 with Visual Studio community 2015 and this solution worked for me.
Basically you need install SQLite bundel and check the "Install the designer component for Visual Studio 2015".
If you have different version from 2015 (2010/2013 etc.) just search for the bundle the suits your version.
1. Go to:
http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
2. Download "sqlite-netFx46-setup-bundle-x86-2015-1.0.104.0" (download the most updated, this is the one I found).
Or by a direct link:
http://system.data.sqlite.org/downloads/1.0.104.0/sqlite-netFx46-setup-bundle-x86-2015-1.0.104.0.exe
3. Run the setup:
4. Result:
You can find installers on the System.Data.SQLite Dowload Page. Seteps files will suit your needs.
For example, the description of the Setups for 64-bit Windows (.NET Framework 4.0) states:
This setup package features the mixed-mode assembly and will install all the necessary runtime components and dependencies for the x64 version of the System.Data.SQLite 1.0.81.0 (3.7.12.1) package. The Visual C++ 2010 SP1 runtime for x64 is included. The .NET Framework 4.0 is required.
None of answers worked for me. in addition to #E235 answer
i added sqlite nuget package
updated ef to 6.1.3
then it worked i was able to see datasource
The release notes cover the MVC2 -> MVC3 path. What about RC2 -> RTM? I installed the RTM via Web Platform Installer but looking to the path that System.Web.Mvc reference in my existing project (C:\Program Files\Microsoft ASP.NET\ASP.NET MVC 3\Assemblies\System.Web.Mvc.dll) has a date stamp of 1/4/11 so that can't be right.
If i use WPI to install RTM, shouldn't i expect it to have upgraded the RC? Are special steps required in instances where the RC had been installed?
thx
You don't need to do anything to upgrade. The RC2 projects are compatible with RTM. And the file date on disk is probably just the date that you installed Mvc, not he version of the mvc dll
Not sure if there is a question in there.
If you installed a newer version of MVC3 on your machine, you'll need to add a new reference to it in your project. Otherwise, your project will stay on the version of the assembly it currently references to avoid breaking changes.
If you find yourself with a lot of problems keeping your assemblies in an up to date reference, check out Microsoft's NuGet project.