I am having an issue with Azure Storage Emulator. I tried to re-initialise the database and got the error below.
This was after installing Visual Studio 2019 Preview but this may just be a co-incidence. I tried for an hour or so to get it running and then gave up and just reset my machine with the "keep my files" option, re-installed Visual Studio 2017 and the Azure Tools but still see the same problem.
I know a reset sounds a bit drastic but VS 2019 broke my Azure Functions in VS2017, they would not launch so I wanted a clean install.
If I manually create the DB with sqllocaldb create (version 13.1.4001.0), the DB gets created fine but the init still fails with the same message.
Any ideas?
C:\Program Files (x86)\Microsoft SDKs\Azure\Storage
Emulator>AzureStorageEmulator.exe init
Windows Azure Storage Emulator 5.7.0.0 command line tool
Found SQL Instance (localdb)\MSSQLLocalDB.
Creating database AzureStorageEmulatorDb57 on SQL instance '(localdb)\MSSQLLocalDB'.
Cannot create database 'AzureStorageEmulatorDb57' : The database 'AzureStorageEmulatorDb57' does not exist. Supply a valid database
name. To see available databases, use sys.databases..
One or more initialization actions have failed. Resolve these errors before attempting to run the storage emulator again.
Error: Cannot create database 'AzureStorageEmulatorDb57' : The database 'AzureStorageEmulatorDb57' does not exist. Supply a valid
database name. To see available databases, use sys.databases..
After resetting my machine (and keeping files), I ran into this issue. For me, I was unable to run an Azure function in Visual Studio 2019 due to an error around being unable to start the emulator.
It looks like I had the same permissions issues as (I presume) my new account after reset, did not have permission to touch the DB.
I resolved this by:
Deleting the Azure Storage Emulator DB file: %USERPROFILE%/AzureStorageEmulatorDb[number].mdf
Then running AzureStorageEmulator.exe start with admin rights
I was then able to run the Azure Function without issue.
Stop the Azure Emulator if it is running.
Open SSMS and connect to your (localdb) instance.
Manually create the "AzureStorageEmulatorDb57".
Open a command prompt as Administrator.
Run the "AzureStorageEmulator.exe init".
Run your VS project.
I was running into this same issue after installing LocalDb for SQL Server 2017. These steps helped me to resolve the problem I was facing:
Open a command line in C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator
Run AzureStorageEmulator.exe init /forceCreate
From checking my error logs (located at %USERPROFILE%\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\MSSQLLocalDB), I saw
2018-12-21 15:41:13.47 spid65 CREATE FILE encountered operating system error 5(Access is denied.) while attempting to open or create the physical file 'C:\Users{username}AzureStorageEmulatorDb59.mdf'.
This error lead me to the following post: https://dba.stackexchange.com/questions/191393/localdb-v14-creates-wrong-path-for-mdf-files
From reading answers there, I gathered that this is a bug in SQL Server 2017. Without having access to the patch, the solution that worked for me was granting Everyone access to modify C:\Users. This was only an issue on my development laptop, so I could afford to make that security change
or as commented by Andrii install CU13 HotFix for SQL Server 2017. After that AzureStorageEmulatorDb<xxx>.mdf will be created you your user directory as it should.
I had this problem and I don't know why an AzureStorageEmulatorDb57_log.ldf was still present in my %USERPROFILE% directory when I deleted my MSSQLLocalDB instance, but after dropping that file the problem went away.
I came across this issue where I had changed the userlogin to my machine. I have created the database from my previous useraccount. I have copied the database files to the new user account but it gave me this error. It seems to be a permission issue.
You need to find the saved location of the mdf and ldf file of this database. In my case it was stored in 'C:\Users\yourUserName'
Simply delete these files and run AzureStorageEmulator.exe init again and it will create the new mdf and ldf files for you.
After manually upgrading my MSSQL 2016 LocalDB to MSSQL 2019 following these instructions, I got the error mentioned as I was unaware that the Azure Storage Emulator uses LocalDB internally.
To fix it, I simply had to manually re-attach the database located in %UserProfile% with the following SQL command:
CREATE DATABASE [AzureStorageEmulatorDb510]
ON (FILENAME = 'C:\Users\<username>\AzureStorageEmulatorDb510.mdf'),
(FILENAME = 'C:\Users\<username>\AzureStorageEmulatorDb510_log.ldf')
FOR ATTACH;
Worked for me:
Delete any storage/sql database related to azure emulator
run this command on StorageEmulator path:
AzureStorageEmulator.exe init /server .
(Or your SQL instance, Mine was ".")
Check you had install Azure SDK with Visual Studio, if you did't you can add the feature
You can locate the mdf and ldf files in your userprofile directory. Just stop the emulator and copy those files to some other place and delete it from userprofile directory.
Then run the emulator again and it's going to create new mdf and ldf files.
Then stop the emulator and copy the old files back and restart the emulator. This way you won't loose any data.
I will help you with this. First of all create a sql server local db.
Then go to storage emulator folder
_-The Storage Emulator is installed by default to C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator.
Then run this AzureStorageEmulator.exe init /server
docs: AzureStorageEmulator.exe init /server localhost\SQLEXPRESS01
Open SSMS and connect to your (localdb) instance.
Manually create the "AzureStorageEmulatorDb...".
To add yet another answer, I did not have the any MDF or LDF files. Instead, I only had a config file at %USERPROFILE%\AppData\Local\AzureStorageEmulator\AzureStorageEmulator.5.10.config. I also could not connect to my local (localdb) instance with SSMS.
I changed the SQLInstance value in that config file to be localhost rather than (localdb)\MSSQLLocalDB, and it started working.
You should have an app called Microsoft Azure Storage Emulator.
Start this application.
If the application indicates that it is running run AzureStorageEmulator.exe stop first otherwise run AzureStorageEmulator.exe Start directly. Should create your database automatically, at least it did for me.
https://learn.microsoft.com/en-us/azure/storage/common/storage-use-emulator
This seems to be because the mdf file already exists but LocalDB doesn't have it attached. You can delete and recreate as others have mentioned, but in my case I was able to just re-attach it and it worked fine.
Open SSMS to (localdb)\mssqllocaldb
Right click Databases
Choose Attach
Click Add
Select the existing MDF file (mine was in my user profile and named AzureStorageEmulatorDb510.mdf)
Click Ok
Then try running the emulator again.
This solution is not recommended in generally, but you can try it.
I think AzureStorageEmulator by somehow can not full access the localDB whitch setup in directory has limited the permission.
You can go to folder propertiy > sercurity > edit to full permission ( with me directory is user > Appdata).
Then restart the emulator
cmd restart the azure emulator.
Now it worked. You must consider it's unsercurity later on.
I initialized the db instance and succeed, bu my SQLServer is 2017.
Then I search the solution and the doc said delete the trouble database will solve the problem. Maybe you can try it follow the steps in the doc.
We are trying to deploy a database project using tfs deployer and "vsdbcmd.exe" (VS 2010 version).
Both are on a windows server 2008 r2 (64 bit).
When our deployment script runs and we call the VSDBCMD.exe, we get the following error:
An unexpected failure occurred: Object reference not set to an instance of an object.
Note: SQL Server is not installed on this server, the script calls to a different server which has the databases we want to execute the database schemas against. Visual studio is also not installed on this server so I executed reg add HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0 as I found a missing registry key could be causing the issue. However, the problem still occurs
The dll's copied to the server are:
Extensions (folder)
DatabaseSchemaProviders.Extensions.xml
Microsoft.Data.Schema.dll
Microsoft.Data.Schema.ScriptDom.dll
Microsoft.Data.Schema.ScriptDom.Sql.dll
Microsoft.Data.Schema.Sql.dll
Microsoft.Data.Schema.Utilities.dll
Sqlceer35en.dll
Sqlceme35.dll
Sqlceqp35.dll
Sqlcese35.dll
sqlceca35.dll
sqlcecompact35.dll
sqlceoledb35.dll
System.Data.SqlServerCe.dll
vsdbcmd.exe
vsdbcmd.exe.config
Any ideas on how to resolve this would be great
Thanks,
Ryan
I am currently working on my product installation in Windows XP 64-bit machine. I am trying to register my COM modules as part of installation. I am doing this by adding an entry in 'RunOnce' (registry) key to launch a bat file and registration is done from that bat file.
All my COM dlls are registered correctly but two of the COM servers (.exe) showing error that it failed to load one of its dependency dll. But the same dll is statically linked with another COM server and this server registered successfully !
And surprisingly running the same bat file directly(double clicking on it) doesn't generate any errors and its works fine for all assemblies!. I have checked this in couple of my test machines only of the machines showing this behavior. Unfortunately that't the customer tool machine.
Its not dependency dll not available issue. Because after registering all files by directly running the bat file, I could reproduce this again by adding a key in RunOnce manually and restarting the machine.
Additional info, I am accessing this machine remotely via logmein.
Exact error message: "This application has failed to start because XXX.dll was not found. Re-installing the application may fix this problem".
This XXX.dll is not available in the same path but its in another folder and its path is available in path variable.
bat file content is;
"C:\WINDOWS\system32\regsvr32.exe" RemoteControlHandler.dll
"C:\WINDOWS\system32\regsvr32.exe" ProcPgmHandler.dll
"C:\WINDOWS\system32\regsvr32.exe" GEM300Handler.dll
"C:\WINDOWS\system32\regsvr32.exe" ICEScreenAdapter.ocx
HIB.exe /regserver //Throws error
JobManager.exe /regserver
Cim300Adapter.exe /regserver
GemEquipmentCtrl.exe /regserver //Throws error
Hope this information is enough for experts, feel free to ask if you need any additional information.
Nixon
I am in Visual Studio Express 2012 for Windows Phone, and have followed the MiniBrowser Tutorial located at the following link:
http://msdn.microsoft.com/en-US/library/windowsphone/develop/ff402526(v=vs.105).aspx
After following all the instructions, once I get to "Run Your App" portion of the instructions, under step 1, Build, the following errors are generated:
Error 1 The name "LocalizedStrings" does not exist in the namespace "clr-namespace:MiniBrowser". c:\users\avery_000\documents\visual studio 2012\Projects\MiniBrowser\MiniBrowser\App.xaml 1 1 MiniBrowser
Error 2 The name "LocalizedStrings" does not exist in the namespace "clr-namespace:MiniBrowser". c:\users\avery_000\documents\visual studio 2012\Projects\MiniBrowser\MiniBrowser\App.xaml 10 9 MiniBrowser
Error 3 The build stopped unexpectedly because of an internal failure.
Microsoft.Build.Exceptions.BuildAbortedException: Build was canceled. Failed to successfully launch or connect to a child MSBuild.exe process. Verify that the MSBuild.exe "C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" launches successfully, and that it is loading the same microsoft.build.dll that the launching process loaded. If the location seems incorrect, try specifying the correct location in the BuildParameters object, or with the MSBUILD_EXE_PATH environment variable.
at Microsoft.Build.BackEnd.NodeProviderOutOfProc.CreateNode(Int32 nodeId, INodePacketFactory factory, NodeConfiguration configuration)
at Microsoft.Build.BackEnd.NodeManager.AttemptCreateNode(INodeProvider nodeProvider, NodeConfiguration nodeConfiguration)
at Microsoft.Build.BackEnd.NodeManager.CreateNode(NodeConfiguration configuration, NodeAffinity nodeAffinity)
at Microsoft.Build.Execution.BuildManager.PerformSchedulingActions(IEnumerable`1 responses)
at Microsoft.Build.Execution.BuildManager.HandleNewRequest(Int32 node, BuildRequestBlocker blocker)
at Microsoft.Build.Execution.BuildManager.IssueRequestToScheduler(BuildSubmission submission, Boolean allowMainThreadBuild, BuildRequestBlocker blocker) c:\users\avery_000\documents\visual studio 2012\Projects\MiniBrowser\MiniBrowser\MiniBrowser.csproj MiniBrowser
What do these errors mean?
Looks like when Visual Studio Express 2012 for Windows Phone installed on my computer, it put the project folder onto the same hard drive as the application. For some reason, the solution in order to get this to compile, was to recreate the project on a different hard drive, and work from there.
Thanks everyone for your assistance!
Background:
I have several builds running on a Windows Server 2003 R2 machine via TFS2010. All of these build definitions have the Path to Publish Symbols set to "\\server\SymbolStore" and the builds run fine.
(Note - I have inherited this set up from a former employee, and I also have other builds running on a separate 2K8 machine that also run without issue)
I am now migrating these builds to a new Windows 2008 R2 build server using the same settings.
Problem:
When running the builds on the new build machine, everything is working fine until the build tries to run the "Publish Symbols" activity in the workflow, at which point I get the error
SYMSTORE ERROR: Class: Server. Desc: Couldn't connect to server.
Error 5: Access is denied. TF270015: 'symstore.exe' returned an
unexpected exit code. Expected '0'; actual '5'.
which also sets the build status to Partially Succeeded.
I have searched the web for these error messages to no avail so far, so does anyone know what might be causing this and how to get it working again?
As always, thanks in advance
Did you check the folder has the right permissions for the service account that is used by Team Build to create/write files ?
Turns out that after I had set up the new build machine, I had left the Credentials for the Build Service Properties (found in the Team Foundation Server Administration Console/Build Configuration) to its default setting which is "NT AUTHORITY\NetworkService". Once I had changed this to use the build service account, the builds are able to write to the symbol store properly