A coworker of mine has this problem, apparently after installing Re#, which seems totally irrelevant. But perhaps it isn't.
Could not load file or assembly "SqlManagerUi, Version=9.0.242.0..." or one of its dependencies. The module was expected to contain an assembly manifest. (mscorlib).
Why is this?
Thanks
I was with a similar problem, i could not open my SQL Server Management Studio.
This steps works for me:
In file C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe.config, erase the item <NgenBind_OptimizeNonGac enabled="1" />.
Example:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<!-- ...snip... -->
<runtime>
<!-- ...snip... -->
<!-- Remove this line (~line 38) -->
<NgenBind_OptimizeNonGac enabled="1" />
<!-- ...snip... -->
</runtime>
<!-- ...snip... -->
</configuration>
I hope this helps.
Reinstalling the .Net framework didn't help me, but these next steps did. I had to completely uninstall and reinsall the shared components, but it's pretty hard to find out how to do that.
Make sure you have the installation media handy. In my case that's the unzipped folder from the downloaded SQLEXPRWT_x64_ENU ed 2014.exe
First, through your Control panel -> Uninstall a program, find 'Microsoft SQL Server 2014 (x64)'.
Right-click and select Uninstall/Change.
When you're presented with a dialog with the options to 'Add', 'Repair' or 'Remove' the product, select the last (don't worry, your SQL Server won't be touched if you follow these steps carefully.
From the initially blank drop-downlist select << Remove shared features only >>
Follow all steps from there, and you are now able to reinstall the shared features.
Management studio requires the .Net framework. Try removing/reinstalling it.
was there any installing/uninstalling of VS involved? Don't get me started on SQL 2005 and VS intall conficts.
Related
Due to a problem with my storage, I need to delete or change location of many folder in my User space, but I see a .nuget folder and I would like to know if there is a way in Visual Studio 2016 to change the location of this folder?
It includes all the packages downloaded for my projects and it takes a lot of space.
Set the globalPackagesFolder propety in your nuget.config and you can point this to any location on your drive. For an overview of the NuGet.config file check out our documentation here.
E.g
<configuration>
<config>
<add key="globalPackagesFolder" value="..\..\GlobalPackages2" />
</config>
</configuration>
This is NuGet cache and can be cleared easily.
In Visual Studio hover over NuGet Package Manger under Tools Menu and click on Package Manager Settings.
Now click on Clear All NuGet Cache(s).
This "Clear All Nuget Cache(s)" will clear all the packages from the default.
You can change the path using NUGET_PACKAGES environment variable
I'm working on a ClickOnce app that's set to online-only. I publish it to an internal IIS server, with an HTML page in the same directory that contains this link:
The deployment looks like so, with all files except the HTML page generated by my project's publish target:
MyAppName
-> Application Files
-> MyAppName_2213_20_0_65
-> <The published files>
-> default.html
-> MyAppName.application
When I click the link, the app runs immediately without any confirmation prompt, and I see from the about box that it's the old version. When I browse to the file share and launch MyAppName.application by double-clicking on it in Explorer, I get the prompt asking me if I'd like to run it, and then it downloads and I get an error:
Unable to install this application because an application with the same identity is already installed. To install this application, either modify the manifest version for this application or uninstall the preexisting application.
As part of the build process, I set the InstallUrl property of the project to http://ourserver/MyAppName/MyAppName.application. Is that wrong? Should it be the HTML page that contains the link? How is it determining the "identity" that's generating a conflict?
Since the app's online-only, it's not installed and doesn't show up in the Programs and Features control panel (and therefore that part of the error message doesn't apply).
I'm new to ClickOnce, so let me know if I left out some helpful information.
Update
If I run mage -cc from a Visual Studio command prompt, the new version launches instead of the old one.
Update 2
As I poked around more, I'm seeing something that looks wrong, and could be the problem. I see the following two lines in my MyAppName.application file (the deployment manifest):
...
<assemblyIdentity name="MyAppName" version="1.0.0.0" ...
...
<dependency>
<dependentAssembly dependencyType="install" codebase="Application Files\MyAppName_2213_20_0_65\MyAppName.exe.manifest" size="82044">
<assemblyIdentity name="MyAppName.exe" version="1.0.0.0" ...
...
You can see the mismatch above. It's deploying to MyAppName_2213_20_0_65, but it thinks the version number of the exe is 1.0.0.0. I'm not sure why it thinks that. My project includes a file that gets generated as part of the build with this line:
[assembly: AssemblyVersion("2213.20.0.65")]
Then, to set the published version number, I have this in my csproj file:
<Target Name="BeforePublish">
<GetAssemblyIdentity AssemblyFiles="$(TargetPath)">
<Output TaskParameter="Assemblies" ItemName="MyAppAssemblyInfo" />
</GetAssemblyIdentity>
<PropertyGroup>
<ApplicationVersion>%(MyAppAssemblyInfo.Version)</ApplicationVersion>
<InstallUrl>$(INSTALL_URL)</InstallUrl>
</PropertyGroup>
</Target>
Does the assembly version listed for my executable even matter? If it does, why is it stuck on 1.0.0.0, and could that be affecting the download of updated versions?
My second update put me on the right track. The problem was indeed the incorrect version number for the assemblyIdentity attributes. To fix it, I'm no longer using a BeforePublish target. Instead, I'm passing in the ApplicationVersion when I call MSBuild:
"%msbuild_path%" MyAppName.csproj /target:Publish /p:ApplicationVersion=%VERSION%
I'm attempting to build a .sqlproj on a TFS Build Server. I've followed the instructions here:
http://sqlproj.com/index.php/2012/03/headless-msbuild-support-for-ssdt-sqlproj-projects/
which I was directed to from here:
How to build .sqlproj projects on a build server?
But I still cannot build. The error is:
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets
(441): The "SqlModelResolutionTask" task could not be instantiated
from "C:\Program Files
(x86)\Common7\IDE\Extensions\Microsoft\SQLDB\Dac\120\Microsoft.Data.Tools.Schema.Tasks.Sql.11.dll".
System.TypeInitializationException: The type initializer for
'Microsoft.Data.Tools.Schema.Tasks.Sql.DataTask' threw an exception.
---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Data.Tools.Schema.Sql, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The
system cannot find the file specified. at
Microsoft.Data.Tools.Schema.Sql.Extensibility.ToolingShim.ConfigureExtensions()
--- End of inner exception stack trace --- at Microsoft.Data.Tools.Schema.Tasks.Sql.DataTask..ctor()
The SqlTasks.targets file, used by the SQL project, references this:
C:\Program Files (x86)\Common7\IDE\Extensions\Microsoft\SQLDB\Dac\120\Microsoft.Data.Tools.Schema.Tasks.Sql.11.dll
which in turn references the invalid version mentioned above.
However, the files installed by the process in the link above don't install this version. They do install version 10.3.0.0, which is referenced by
C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\Microsoft.Data.Tools.Schema.Tasks.Sql.12.dll
but this file is not the one used by the .targets file.
I don't know what the numbers at the end of this dll mean, but it seems odd to me that the one ending 12.dll references an earlier version of the one ending 11.dll.
I'm using Visual Studio 2013 and SQL Server 2012 - neither of which are installed on the build server, which I believe is the recommended situation. I don't know what the IDE folder is, or why the .targets file is using it.
I've spent about two days now trying to get this to build, but I'm out of ideas. Anyone know what's going on?
If you are running VS2013 SSDT is built into VS as long as you select it on the install screen. Install VS2013 with SSDT onto your build server. create a build definition and under Process > Build > Advanced Add the following to the MSBuild arguments to build the sql proj
/t:Build
if you have a publish profile and want to test publishing to SQL then add the publish switch and provide the link to the profile file
/t:Publish /p:SqlPublishProfilePath=MyDB.publish.xml.
this will publish the db to the server specified in the publish file.
the publish profile file can be created by opening the project in Visual Studio, right click on the project and select publish. Select save once you are happy with the publish options and then check in the file to source control so the build can find it, (project Root).
I was having this issue building a SQL Server project on an Azure DevOps CI/CD pipeline. None of the pre-built build tasks would work for me. And it is not possible to install a VS instance on the build server, I guess.
I solved this by avoiding to add a SQL Server project to the solution.
I achieved this by using an MSBuild SDK, capable of producing a SQL Server Data-Tier Application package (.dacpac) from the set of SQL scripts. By adding this second project to the solution, I managed to continue taking advantage of linking the project to a live database through SQL Server Object Explorer on Visual Studio. I gave a more detailed explanation in this answer.
Having upgraded to Visual Studio 2013, I have found that an old SQL project fails to load when I attempt to open a solution. The error displayed is:
The imported project "C:\Program Files (x86)\MSBuild\12.0\bin\SqlServer.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk. C:\Some\Path\To\Project\Database.sqlproj
In my .sqlproj file I have the line
<Import Project="$(MSBuildToolsPath)\SqlServer.targets" />
which in Visual Studio 2012 resolves to C:\Windows\Microsoft.NET\Framework\v4.0.30319\SqlServer.targets but in Visual Studio 2013 this resolves to C:\Program Files (x86)\MSBuild\12.0\bin\SqlServer.targets. However, the SqlServer.targets file is in neither of these locations.
Presumably this is due to MSBuild becoming part of Visual Studio, rather than it being part of the .Net Framework.
Does anyone know how to fix this issue and to migrate this project to Visual Studio 2013?
Just copied SqlServer.targets from C:\Windows\Microsoft.NET\Framework\v3.5 to C:\Program Files (x86)\MSBuild\12.0\Bin and it helps. VS2013 is now able to open the old project.
I had a similar problem when upgrading from Visual Studio 2008 to 2013.
It took awhile but I had to install the SSDT for VS 2013 (again), then I created a new database project to find out the relative path to the new sqlserver.targets file.
It should be as follows:
<Import Condition="'$(SQLDBExtensionsRefPath)' != ''" Project="$(SQLDBExtensionsRefPath)\Microsoft.Data.Tools.Schema.SqlTasks.targets" />
<Import Condition="'$(SQLDBExtensionsRefPath)' == ''" Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" />
The biggest hindrance that I found to fixing this error was trying to understand the error message provided (BC2014: the value 'database' is invalid for option 'target')
Hope this helps!
I had the same problem and I solved this way:
Just create a file named 'SQLServer.targets' on 'C:\Windows\Microsoft.NET\Framework\v4.0.30319' with the following content:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<SqlClrTargetsFullPath>$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\TeamData\Microsoft.Data.Schema.SqlClr.targets</SqlClrTargetsFullPath>
</PropertyGroup>
<Import Project="$(SqlClrTargetsFullPath)" Condition="Exists('$(SqlClrTargetsFullPath)')"/>
</Project>
Good luck.
This can also occur when opening an older project in Windows 10
I had the same problem (SqlServer.targets was not found) when opening an old SQL Server CLR assembly in Visual Studio 2010 on Windows 10, the same version used originally to write the assembly.
Confirmed the same project opened perfectly fine in Visual Studio 2010 on a Windows 7 computer.
Solution
Pay attention to the error message. In my case it was:
The imported project “C:\Windows\Microsoft.NET\Framework\v4.0.30319\SqlServer.targets” was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
Simply copy SqlServer.targets from the location indicated in Vladimir Dronov's answer, "C:\Windows\Microsoft.NET\Framework\v3.5\SqlServer.targets", to the directory indicated in the error message.
In my case that was "C:\Windows\Microsoft.NET\Framework\v4.0.30319\".
I had the same problem when trying to build a VS 2010 solution under VS 2013. The fix was to upgrade the solution file to VS 2013 first. After that it worked without further modifications.
The Error Resulting from Several of these Solutions
I posted a specific question (C# VS 2013 Error 02019: Invalid target type for /target: must specify 'exe', 'winexe', 'library', 'module', 'appcontainerexe' or 'winmdobj' CSC) regarding the fatal build error described by Chris Torng below Vladimir Dronov's answer:
Error 1 02019: Invalid target type for /target: must specify 'exe', 'winexe', 'library', 'module', 'appcontainerexe' or 'winmdobj' CSC
The Fix
I was able to get rid of the error related to SQL Server dev tool compatibility issues in VS2013 Community Edition by following the advice in this forum:
https://connect.microsoft.com/SQLServer/feedbackdetail/view/979839
Posted by bsclifton on 11/15/2014 at 7:18 AM
Had this issue too with the Community 2013 edition; Going to Tools->Extensions and Updates and updating "Microsoft SQL Server Update for database tooling" resolved the issue :)
If this doesn't work for you, I'd recommend checking out that forum as it offers up several other ideas for how to fix the problem
Solution 1:
If the project is a .csproj file, you should check if Visual Studio also generated a .sqlproj file while upgrading. If that is the case, you can add that to the solution instead.
Solution 2:
You can try to change the following line in the .sqlproj file:
<Import Project="$(MSBuildToolsPath)\SqlServer.targets" />
to
<Import Project="$(MSBuildBinPath)\SqlServer.targets" />
I have a very peculiar issue using Azure Table Storage. I have a .NET 4.5 project in Visual Studio 2012 where I deal with all my Azure Table Storage functions. This project/dll is referenced by two other projects, my MVC website, and my Azure Worker Role. (I am running under the Azure Emulators on my machine, but it also happens when I deploy it to the cloud)
I have the following function that is called when I save or retrieve a record:
internal static CloudTable GetTable(CloudStorageAccount storageAccount, string tableReference)
{
CloudTableClient tableClient = storageAccount.CreateCloudTableClient();
CloudTable table = tableClient.GetTableReference(tableReference);
table.CreateIfNotExists();
return tableClient.GetTableReference(table.Name);
}
In my MVC website I have a function that will save a record to a Azure Storage table, and then in my Azure Worker Role there is a service that will read the record.
So both uses the same dll for storage and retrieval, however my MVC project has no issues saving the record, but in my Azure Worker role service when it tries to retrieve the record throws the exception when it attempts to execute "table.CreateIfNotExists();".
Could not load file or assembly 'Microsoft.Data.OData,
Version=5.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or
one of its dependencies. The located assembly's manifest definition
does not match the assembly reference. (Exception from HRESULT:
0x80131040)
I have done the following already:
Updated all the NuGet packages from the solution level to the latest versions
I went through every project reference to make sure that there are no old dll's or previous versions hanging around, in particular the System.Spatial, Microsoft.WindowsAzure.Configuration, Microsoft.WindowsAzure.ServiceRuntime and Microsoft.ServiceBus, Microsoft.WindowsAzure.Storage, Microsoft.Data.Edm & Microsoft.Data.OData
I have even created a new Cloud Service and WorkerRole project from scratch to make sure it is not something in the current WorkerRole project that is broken.
I have not rolled the dll's back to 5.2 as I had too many issues in other projects where I use features that are specific from 5.3 onwards.
I am currently running all the dll's on 5.5.
When I run the AsmSpy.exe utility found here, I get the following output that I am not 100% sure how to interpret.
> Reference: Microsoft.Data.Edm
> 5.5.0.0 by Microsoft.Data.OData
> 5.5.0.0 by Microsoft.Data.Services.Client
> 5.5.0.0 by Microsoft.WindowsAzure.ActiveDirectory.GraphHelper.2013_04_05
> Reference: System.Spatial
> 5.5.0.0 by Microsoft.Data.OData
> 5.5.0.0 by Microsoft.Data.Services.Client Reference: Microsoft.Data.OData
> 5.5.0.0 by Microsoft.Data.Services.Client
> 5.2.0.0 by Microsoft.WindowsAzure.Storage <-- THIS SEEMS TO BE THE ONE THAT IS CAUSING ISSUES
How I interpret it, is that the Microsoft.WindowsAzure.Storage dll is referencing V 5.2.0.0 of the Microsoft.Data.OData dll, but how do I fix this, if this is the issue? According to the documentation I have seen on the Storage dll is that it is supposed to reference 5.4 and up, not 5.2...?
Opening issue for such an easy to solve issue will not help you.
Put the following addition configuration in your respective config files (web.config for the MVC and app.config for the worker role):
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.OData" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Note that runtime section is direct descendant of the configuration root element! I'm pretty sure you already have this section in your web.config, because MVC4 uses it to rebind all references to System.Web.MVC to the latest version.
I personally do not expect the SDK to be updated with every new version of every referenced library! This would be madness...
I had a very similar problem but in this case it exception message was;
Could not load file or assembly 'Microsoft.Data.OData,
Version=5.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or
one of its dependencies. The located assembly's manifest definition
does not match the assembly reference. (Exception from HRESULT:
0x80131040)
note it was trying to load v5.5.0.0 of the OData assembly.
After some digging around with ILSpy (http://www.ilspy.net) I discovered that Microsoft.WindowsAzure.Storage 2.0.0.0 was explictly referencing Microsoft.Data.OData 5.2.0.0 - which I didn't have as my version was 5.5.0.0.
So the solution was to use the NuGet package manager to uninstall Microsoft.WindowsAzure.Storage, this inturn uninstalled Microsoft.Data.OData 5.5. Then again using the NuGet package manager, reinstall Microsoft.WindowsAzure.Storage which identified that it needed Microsoft.Data.OData 5.2 and installed that too.
and back to a working solution.
You can solve this issue in general whenever you update packages or add new packages via NuGet and end up with "Could Not Load file or Assembly..." issues.
Open the Package Manager Console (VS 2012 Tools/Library Package Manager/ Package Manager Console). Once the shell opens for the Package Manager Console run the command:
Add-BindingRedirect
Note: Be careful as the NugGet example added an 's' to the end in their example and Add-BindingRedirect is not a valid command.
This does the following:
Examines all assemblies in the output path for a project and adds
binding redirects to the application configuration (app.config) file
or to the web configuration (web.config) file where required.
You can see complete documentation for the Package Manager Console at: http://nuget.codeplex.com/wikipage?title=Package%20Manager%20Console%20Command%20Reference%20(v1.3)
In addition to the two entries you see in astaykov's answer the following was also added for my Project.
<dependentAssembly>
<assemblyIdentity name="System.Spatial" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>
I had similar problem today. The only difference I spotted is my cloud app was looking (and failing to find) for Microsoft.Data.OData in Version=5.2.0.0
Using Visual Studio Object Browser i found out that my solution used library from that location:
C:\Program Files (x86)\Microsoft WCF Data Services\5.0\bin\.NETFramework
Microsoft.Data.OData library residing there was in ver. 5.0.0.0 so overwriting it with 5.2.0.0 resolved the problem.
P.S. I installed WCF Data Services Tools for Windows Store Apps earlier in hope of resolving this issue so it may happen that your application gets it from another source. If that is the case you have two options:
Install WCF Data Services Tools for Windows Store Apps from here and use solution above.
Use Visual Studio Object Browser to find what versions of OData library are currently visible for your project and where they are stored. Next you need to overwrite improper versions of them.
I had a similar problem as well, but I wasn't using Azure and there was no hard-coded reference that was pointing to 5.2. But it resolved (after finding this article) by making sure that the text in the .svc pointed to the correct assembly:
<%# ServiceHost Language="C#"
Factory="System.Data.Services.DataServiceHostFactory,
Microsoft.Data.Services, Version=5.6.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35"
Service="MVC4WCFDataServiceFE5.NorthWindService" %>
Note the Version=5.6.0.0, which I didn't have before.