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
Related
Am using Windows Server machine 2012 R2 machine to take a setup (exe) and using Wix v3.10.
When i run the burn executable taken from Windows Server 2012 R2 machine in any machine, setup crashed with the error as "System.IO.DirectoryNotFound" not found.
On further investigating this, this exception was occurred during the retrieval of burn and bootstrapper related files(.ba folders from temp location) using WixBundleProviderkey. Because, the .ba folder was existing in some other (some Guild(folder name)} name instead of the required directory in temp location. This issue is occurred only when the setup taken from Windows Server 2012 R2 machine and this is not occurred in some other windows machine if we took setup from it.
Actual path in which .ba folders exists: C:\Users\server\AppData\Local\Temp\2{32DB2298-79D9-4816-9BD6-ABA4271CCA2F}
Application Searching path of .ba folder : C:\Users\server\AppData\Local\Temp\2{36823a7e-b6d2-4db1-b0d1-212cdf7bd669}\
Could anyone please let us know why this issue occurring in Windows server machine?
What is the main function of WixBundleProviderkey?
Below is my code where am facing issue while launching the setup
string baFolder = System.IO.Path.GetTempPath() + SyncBA.Model.Bootstrapper.Engine.StringVariables["WixBundleProviderKey"] + "\";
This is due to the security mitigations added in v3.10.3. That temp folder is no longer created using the bundle's id, it's a random guid. You should get the location of your BA in a different way, such as AppDomain.CurrentDomain.BaseDirectory.
I am having a problem with using Apache/Perl to get access to Excel files using Microsoft Data Access Component (MDAC). Somehow I must set the "CommonProgramFiles(x86)" system environment variable in order to get this to work. Otherwise, I keep getting this error message:
System.InvalidOperationException: The .Net Framework Data Providers
require Microsoft Data Access Components(MDAC). Please install
Microsoft Data Access Components(MDAC) version 2.6 or later. --->
System.IO.FileNotFoundException: Retrieving the COM class factory for
component with CLSID {2206CDB2-19C1-11D1-89E0-00C04FD7A829} failed due
to the following error: 8007007e.
The server configuration is:
Windows Server 2008 R2 in 64-bit
Server is installed with Microsoft Access Database Engine 2010
Apache 2.2.25 (that is 32-bit)
Perl 5.12.3 v5 (that is also in 32-bit)
I have my Perl CGI script to call my C# program (that is built for "Any CPU").
The C# program uses MDAC to open and read Excel files (not trying to launch Excel, only try to read data from the Excel files).
I have verified that the server has the latest MDAC available in these 2 folders:
C:\Program Files\Common Files\System\Ole DB
C:\Program Files (x86)\Common Files\System\Ole DB
I have also checked the registries and they look fine. Anyway, I don't have any problem running my C# program directly at the command prompt (it can use MDAC to get access to Excel files). I only have the problem when I use Apache/Perl to use my Perl CGI script to call my C# program (that is when I get that error with MDAC).
I can work around this problem by specifying CommonProgramFiles(x86) in my Perl CGI script, like this:
$ENV{ "CommonProgramFiles(x86)" } = "C:\\Program Files (x86)\\Common Files";
I have this question:
Why do I have this problem? And why setting that CommonProgramFiles(x86) system environment variable can workaround this problem? Why that system environment variable is empty before I set it? Does this have to do with the fact that I am running 32-bit Apache/Perl in a Windows operating system that is 64-bit?
Please help me to understand this issue. Thanks in advance.
(The original version of this post had a question about a second problem. Turned out that problem had to do with an extra double quote in the string. I fixed this, and that problem has gone away. That's why I have removed that second question from the post)
Jay Chan
I did some more research and the issue is the following: until release 2.4.9, the Apache startup routines have mapped "commonprogramfiles(x86)" to "commonprogramfiles_x86_" and that variable does not exists in the environment unless you create it... I have not tested it, but creating that environment variable and making it point to the same location as commonprogramfiles(x86) would probably fix the issue too.
Since the compiled Apache distributions are only using up to version 2.4.46 as we speak, they don't have the fix that allows the parenthesis in environment variables. That's why you still need the PassEnv directive to ensure that Apache passes the correct values to 32-bit CGI scripts.
The following post has some useful details about this:
https://bz.apache.org/bugzilla/show_bug.cgi?id=46751
I used to have the same problem in with Apache 2.4 with dBase compiled apps using ADO-32 bit as dBase is 32-bit. Something has recently changed, possibly with Windows 10 2004 20H2. I needed this fix in July-Aug 2020 but now I don't, the environment variable already exists. Since my Apache version is dated April 2020, that cannot be the reason for the change.
I tried to do some research about this but all I could find is that those environment variables are system ones existing at least since 2017, so why I needed to set this var is a mystery to me, but I would like to understand this, so if you find something, post a follow-up...
https://learn.microsoft.com/en-us/windows/deployment/usmt/usmt-recognized-environment-variables
I am getting the following error when I attempt the following actions in sequence.
Start Debugging.
Log in as a User.
Stop Debugging.
Clean Build
Without closing browser or logging out start Debugging again.
Attempt to Edit or Create or Update some database record.
If the user is not logged in or the browser is closed the error does not occur. I have even upgraded the SQL instance referring this SQL Server: attach incorrect version 661.
The database 'C:\USERS\ME\DOCUMENTS\VISUAL STUDIO 2012\PROJECTS\PROJ1\PROJ1\APP_DATA\ASPNETDB.MDF' cannot be opened because it is version 661. This server supports version 662 and earlier. A downgrade path is not supported.
Could not open new database 'C:\USERS\ME\DOCUMENTS\VISUAL STUDIO 2012\PROJECTS\PROJ1\PROJ1\APP_DATA\ASPNETDB.MDF'. CREATE DATABASE is aborted.
An attempt to attach an auto-named database for file C:\USERS\ME\DOCUMENTS\VISUAL STUDIO 2012\PROJECTS\PROJ1\PROJ1\APP_DATA\ASPNETDB.MDF failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share.
I am testing this on Chrome.
Any Ideas on what area of either MVC Code/ SQL/ Web.Config I should look for to find the cause of this error. I haven't changed the default Membership that is created with VS2012 when you start a new project.
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
I have about 160 SSIS packages that I'm trying to upgrade from 2005 to 2008.
When I run SSISUpgrade.exe on them, I get the following error messages on many of the packages:
Error 0xc0209303: ...: SSIS Error Code DTS_E_OLEDB_NOPROVIDER_64BIT_ERROR. The requested OLE DB provider MICROSOFT.JET.OLEDB.4.0 is not registered -- perhaps no 64-bit provider is available.
enter code here`Error code: 0x00000000.
An OLE DB record is available. Source: "Microsoft OLE DB Service Components" Hresult: 0x80040154 Description: "Class not registered".
This fellow says that to fix this I need to set the run64bitruntime debugging property to False.
However each of these packages exists outside of a project file. How can I set this property without having a project file?
Ok, if I turned off the check box to validate when running SSISUpgrade.exe it seemed to convert everything ok.
Then I just have to call the packages using the 32 bit dtexec found in C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn
I guess that's good enough for me.