I've read a lot around TFS deployment of SSIS packages - I have a VS2012 SSIS project and have created a .proj file using "DeploymentFileCompilerTask" to build the project into a .ispac:-
<UsingTask TaskName="DeploymentFileCompilerTask" AssemblyFile="..\tools\IntegrationServices.Build\Microsoft.SqlServer.IntegrationServices.Build.dll" />
...
<DeploymentFileCompilerTask
InputProject="$(SSISProjPath)"
Configuration="Release"
RootOutputDirectory="$(OutDir)"
ProtectionLevel="DontSaveSensitive">
i.e. the technique as outlined :-
https://gist.github.com/kulmam92/6433329
However the build is failing with :-
"Could not load file or assembly 'Microsoft.SqlServer.DTSRuntimeWrap, Version=11.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified."
The question I have is what is the minimum I need on the server that executes the above. I have read SSDT and/or SSIS needs to be deployed - there is also a technique relating to recompiling a Codeplex project (as outlined in http://sqlblog.com/blogs/jamie_thomson/archive/2010/09/14/ssis-msbuild-task-now-included-in-msbuild-extension-pack.aspx) or combining particular components of SQL Server (http://www.networksteve.com/enterprise/topic.php/SSIS_Package_Deployment_to_Server_only_running_SSIS_(and_not_SQL/?TopicId=29646&Posts=2).
I don't really want to get too granular, I just wanted a definitive answer to a fairly common problem - can anyone assist.
To anyone who has the same problem, the issue was 32-bit Vs 64-bit related - not the fact that the deployment was lacking a binary (in the GAC, etc)
Within the Build Definition (default build.xml file) go to Process | Advance | MSBuild Platform | Change from 'Auto' to 'X86'
Related
Having trouble getting MSBuild/Visual Studio 2012 to deploy a CRM 2011 Plugin Assembly to a named CRM Solution.
I've 2 project/SLNs. In one, I can precisely control which CRM Solution the build deploys a Plugin Assembly into; my msbuild (call this build-1) creates a CRM Solution with my custom entities/forms and Plugins. In another, despite specifying the exact values via msbuild /p for CRMOrganization, CRMSolutionName, CRMDiscoveryServer, 'CRMDiscoveryServerScheme, the resulting CRM Solution contains only the entities/forms. The Plugins are deployed but placed incorrectly into the Default Solution (call this build-2).
I've created build-2 from copy/pasting the values (except SLN and Project names) from build-1...and am at a loss to understand why build-1 deploys the plugins to my named CRM Solution, but build-2 deploys them to the Organization's Default CRM Solution.
Any ideas?
CRM might look specifically at Display name instead of Schema Name as the solution Name.
Unfortunately the CRM Developer Toolkit in both VS010 and VS2012 versions is configured at the solution level only. Therefore, despite adding multiple projects to your solution they will both use the CRM Organisation settings at the solution level. It's a rather annoying limitation that's existed since the first release of the tooling I'm afraid.
The MSBuild target file used by VS (Microsoft.CrmDeveloperTools.CrmClient.target) is available at the default install location C:\Program Files (x86)\MSBuild\Microsoft\CRM. This folder also includes the supporting assembly containing the MSBuild Tasks if you felt like rolling your own build target.
I've looked at this briefly myself in the past but a word of warning, many of the classes in that assembly are sealed so extending them is off the table.
I am trying to deploy Visual Studio 2012 SSDT project to Sql Server using TeamCity 8 and MSBuild Publish task but the deployment fails.
When I look at TeamCity logs and use /v:diag switch in my build configuration I see that for unknown reason MSBuild searches for MyProject.sqlproj.publish.sql and for MyProject.sqlproj.dacpac files.
The exact error:
[SqlPublishTask] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets(1233, 5): File "C:\Program Files\TeamCity\buildAgent\work\abf8bc05a2cfe7f\*MyProject*\bin\Debug\*MyProject*.sqlproj.dacpac" does not exist.
The correct .sql and .dacpac files get generated (without the .sqlproj in the middel) in buildAgent/work/identificator/*MySolution*/MyProject/bin/Debug folder.
My TeamCity build step is configured as follows:
Runner type: MSbuild
Build file path: MyProject/*MyProject*.sqlproj
MSBuild version: 4.5
MsBuild ToolsVersion: 4.0
Run platform: 4.0
Targets: Publish
Command line parameters: /p:SqlPublishProfilePath="Debug.publish.xml" /p:Configuration=Debug
If I execute this from commandline I get no errors.
Any ideas on how can I configure TeamCity to search for correct files or configure my project to generate the files that TeamCity is searching for.
Or is my plan to use MSBuild's Publish task futile and I should utilise sqlpackage.exe instead?
UPDATE
After spending almost three days trying to figure this out I gave up and used sqlpackage.exe which works like a charm.
But I would still be interested in an answer though, passing paths to executables in build servers seems a bit crude way to accomplish things.
I had a similar issue and came to the conclusion that the way TeamCity produces "pseudo-project" files with *.teamcity suffixes is confusing something in the MSBuild/SSDT target chain.
I simply replaced the MSBuild runner build step with a pure Command Line step and the problem went away.
We lose the user friendliness of the TeamCity MSBuild runner configuration, but if it works, it's a compromise I'm willing to make.
Note - we are running TeamCity 7 - I am not sure if this has been addressed in later versions.
I found out you can set a System Property named "system.SqlTargetName" on the build configuration to override the default value.
Setting this to your project name without the ".sqlproj" makes the error go away.
I'm to use nunit-console to run all of the tests in my solution.
I did this:
c:\some\path>nunit-console-x86.exe MySolution.sln
NUnit-Console version 2.6.2.12296
Copyright (C) 2002-2012 Charlie Poole.
Copyright (C) 2002-2004 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov.
Copyright (C) 2000-2002 Philip Craig.
All Rights Reserved.
Runtime Environment -
OS Version: Microsoft Windows NT 6.1.7601 Service Pack 1
CLR Version: 2.0.50727.5466 ( Net 3.5 )
ProcessModel: Default DomainUsage: Default
Execution Runtime: net-3.5
Could not load file or assembly 'MyNamespace.Administration, Version=0.0.0.1, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
So, I decided to try nunit-x86.exe I did File > Open Project > MySolution.sln and got this:
---------------------------
NUnit
---------------------------
Test load failed!
System.IO.FileNotFoundException : Could not load file or assembly
'MyNamespace.Administration, Version=0.0.0.1, Culture=neutral,
PublicKeyToken=null' or one of its dependencies. The system cannot
find the file specified.
For further information, use the Exception Details menu item.
---------------------------
OK
---------------------------
The exception can be found here
What is happening and how do I fix it? (without having to maintain a MySolution.nunit file)
More information
MyNamespace.Administration is not even one of the dlls that contains tests, which means that nunit fails trying to load it to look for tests to run. Knowing this I edited the file created by nunit-x86.exe (MySolution.nunit) and removed all dlls that did not have tests. Sure enough, the tests work (in both gui and console). This is not acceptable for me because it would mean that I have to keep yet another configuration file. Nunit supporting .sln files was supposed to avoid this.
My tests run fine using TestDriven.Net (but I really need to run them using nunit-console)
I have looked at this answer but I cannot make sense of what the fusion log viewer says. Would posting that log help? Assembly binding Log Viewer, lists 3 files being created:
nunit-agent-x86.exe, this one seems to be trying to find MyNamespace.Administration.dll/EXE inside the nunit directories
Tests_24398275 x2 - one looking for nunit.core in my project folders and another looking for unit.core.interfaces inside my project folders. I would pay little attention to these two since they also appear in my manually edited .nunit project).
(per andreister comment) The problem seems to be with the project/assembly itself and not the creation method. If I create a .nunit project and try to add MyNamespace.Administration to it (using 'Add Assembly...' or 'Add VS project...') it fails.
Calling nunit-console-x86 somepath/bin/Debug/MyNamespace.Administration.dll directly works.
Reposting my reply on nunit-discuss:
The NUnit feature of loading VS solutions is really fairly limited and intended to work with simple projects or as a quick way to create an NUnit project file - i.e. load the solution and save as an NUnit project, then edit the xml file that is created. Since the solution file format doesn't indicate which files are tests, NUnit attempts to load each project to check if it contains any tests. (This is the same thing that Visual Studio 2012 and later does when using the test explorer window, btw.)
As you suggest, I think the particular assembly fails to load because of having a dependency that is one level up. When loading either a VS solution file or an NUnit project file, NUnit sets the application base to the directory containing the solution or project. That's why an NUnit project file one level up works.
The designers' intent in this sort of situation is that you would create an NUnit project file. I recognize that this is somewhat inconvenient, since it gives you another configuration file to maintain. I'm open to suggestions regarding the use of globs either on the command line or within the project file. Any such changes would probably go into the next major upgrade, NUnit 3.0.
Unfortunately, even after posting on nunit-discuss group I was unable to find a proper solution for this problem.
nunit-discuss group confirmed that my tests are failing because of having a dependency that is one level up.
I did however found an acceptable work-around.
Since calling the .dlls directly didn't have the same issues.
I could do this with globs, but I'm on windows... but I have git bash installed.
Taking advantage of my somewhat rigid project structure and naming convention I managed to do this:
"C:\Program Files (x86)\Git\bin\bash.exe" -c 'nunit-console-x86.exe //framework=net-4.5 //xml:nunitresults.xml MysolutionFolder/Tests/*/bin/Debug/*.Tests.dll'
Please note that I took advantage of my naming convention. This is very important to do in order to reduce the number of arguments.
When I did nunit-console-x86 MysolutionFolder/*/*/bin/Debug/*.dll instead of MysolutionFolder/Tests/*/bin/Debug/*.Tests.dll I got an error from nunit-console-x86 saying Bad file number.
Besides, it's faster if I just provide the right files.
If you have a more recent version of bash (4.0+, I think) you can instead use the following command (note the use of **):
"C:\Program Files (x86)\Git\bin\bash.exe" -c 'nunit-console-x86.exe //framework=net-4.5 //xml:nunitresults.xml MysolutionFolder/**/bin/Debug/*.Tests.dll'
Which is shorter and more permissive on the project structure.
iam creating setup file in ado.net but whenever i build my project it is give me 'oledb32.dll' should be excluded because its source file 'C:\Program Files\Common Files\System\Ole DB\oledb32.dll' is under Windows System File Protection error so that's why i download in net and try to import that dll in my project but this file cannot import detected dependencies folder ..oledb32.dll file is important for show patient details in excel format so can you all expert give me any suggestion or advice
I ran into this issue as well and couldn't find a concrete answer until now.
I'm using a development box, checking in code via SVN, and running CruiseControl.NET to execute devenv.exe to automatically build the project (I don't use MSBuild because Microsoft hasn't implemented a solution for building Setup projects yet, and I assume this is what you are also using). The setup project would build fine on the dev box but on the build server it kept coming up with that same error.
The MSDN explanation can be found here, it's not very descriptive, but that's basically what needs to be done. The more concrete answer can be found here. Basically you have to open up VS on your build server and go in and exclude oledb32.dll (and any other problem files) and voila it finally builds and creates the MSI file! Hope this was helpful for you.
Hello I am trying to deploy asp.net MVC 4 project on azure
but I get this problem. I searched a lot about the solution but it looks like none
suit my case, this is the Error message I get :
Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its
dependencies. The located assembly's manifest definition does not
match the assembly reference. (Exception from HRESULT: 0x80131040)
Before the dotnetopenAuth have no reference in my project I downloaded
but still get the same error .
Anyone have an idea?
I know this is old, but I came across a similar problem and this question popped up as the closest case. This was my issue:
http://developers.de/blogs/damir_dobric/archive/2013/09/26/windows-azure-websites-error-could-not-load-file-or-assembly-dotnetopenauth-core.aspx
Being, a previous MVC project had been deployed, which contained these references. I deleted them by downloading the publish profile, and, with the "Remove additional files at destination" option checked, I published to Azure.
While publishing, you can select "Remove additional files at destination" and then publish again.
I ran into this issue with continuous deploy between visual studio online and azure.
I modified my build file and changed the "Do Not Delete" setting under "Deployment" in the "Process" Tab to False.
Good to go.
This is a case of version mismatch. The error itself says that manifest definition does not match.
Look carefully at the version of the referenced assembly and the version shown in error message.
In case you are not using openauth you can remove it's reference all together.