I am using TFS 2013 Build Server.
Getting the following Error
Exception Message: Unable to create the workspace '' due to a mapping conflict. You may need to manually delete an old workspace. You can get a list of workspaces on a computer with the command 'tf workspaces /computer:%COMPUTERNAME%'.
Details: The path F:\GDC\Bin is already mapped in workspace ''. (type MappingConflictException)
I have multiple build Definition which refers to common binary folder
Source Setting for Build definition BD1
Source Control Folder Build Agentfolder
$/Common F:\GDC\Bin
$/Project1 $(SourceDir)
Source Setting for Build defination BD2
Source Control Folder Build Agentfolder
$/Common F:\GDC\Bin
$/Project2 $(SourceDir)
Source Setting for Build definition BD3
Source Control Folder Build Agentfolder
$/Common F:\GDC\Bin
$/Project3 $(SourceDir)
This occurs (as the error suggests) when you have a workspace clash on the build server. Workspaces are saved as configuration values in the TFS database so clashes are possibly caused by:
you have created a new build definition with the same name as a previous build definition.
some part of your workspace name (or an artifact within your project) is over 260 chars
build definition is not using $(sourcedir) macro in System Settings tab
More details are explained in this article
Work-around:
Rename your build definition to something unique.
Here is how I did it:
First, tried to list the workspaces on the server in question. I tried through both Visual Studio UI and command prompt: tf workspaces /computer:. The workspace that is mentioned in the Exception message did not show up in the list.
Downloaded and installed Team Foundation Sidekicks 2015 from http://www.attrice.info/downloads/
When the app installed, opened and connected to tfs server.
Selected the computer name from the dropdown, cleared the Owner name (VERY IMPORTANT!) dropdown from the dropdown and changed Last access date to a date few years ago.
Clicked Search button. The list of workspaces appeared. This time I could see the workspace that was mentioned in the Exception message.
Selected the workspace that is mentioned in the Exception message and clicked Delete button.
It appears that when I login to the build server and ask for the workspaces list, tfs only shows me the workspaces of which I am the owner. The temporary workspaces that build process creates were not assigned to me and therefore I could not see them. Team Foundation Sidekicks 2015 did show me all of the workspaces.
Note: I used TFS2015 in this exercise.
So you have a Workspace conflict.
The easiest way to explain to fix this is to delete your workspaces and make them over again.
You'll need to use the TF tool.
TF /workspace /delete....
There is a TFS sidekicks tool that should be able to do this for you with a GUI.
http://www.attrice.info/cm/tfs/
The reason was (for me) that I have cloned the build definitions. So every "Build Agend Folder" in Source Settings points to the same target folder.
Solution was to change the Build Agent Folder to something special for each build.
e.g. $(SourceDir)\project1
$(SourceDir)\project2 etc
I had the same problem. My solution was that in Edit Build Definition > Source Settings, a Build Agent Folder was not prefixed with $(SourceDir), but instead the full path on my local machine.
I changed the path to be prefixed with $(SourceDir, and my problem was solved.
I have rename build definition name and it started working.
Related
I am having some trouble with BizTalk saying a schema doesn't exist when it does exist.
I can see it in the BizTalkMgmtDb using
select * from bt_documentspec where msgtype like '%myschema%'
I can see it in the BizTalk Server Administration Console > <All Artifacts> > Schemas > My Schema.
This paragraph is optional. I'm only including it so you know I already tried the answer you get when you google this problem.
The exact error message I get is something like "This Assembler cannot retrieve a document specification using this type" which if you google that tells you the schema is either not deployed or the root element you're using exists in two separate namespaces so you should supply a DocSpecName on the SendPorts XMLTransmit 1 2.
I've also tried reinstalling the dll that contains the problem schema into the GAC as per the answer to this question. That didn't work either but now I have more questions anyways.
if I do gacutil -l none of my assemblies are listed there.
So I was wondering what does this even do?
Because those assemblies are not listed under gacutil -l. Also when you look at those assemblies
it shows a source location and a destination location.
Why? Why not just THE location? I can't even find %BTAD_InstallDir% on my computer so there are a minimum of 4 possible locations where this schema dll might be.
source location
destination location (%BTAD_InstallDir%)
"the GAC"
wherever it actually is because there doesn't seem to be a %BTAD_InstallDir%.
So if I want to "update the GAC" to make sure this schema is there how do I do that? What dll is BizTalk ACTUALLY using? The one in %BTAD_InstallDir% or the one in the GAC?
BizTalk 2010.
It has nothing to do with where the DLL is, it has to do with the fact that either
The XML payload namespace and root node does not match any schema
You have two or more schemas with exactly the same namespace and root node that match.
If you don't have any namespace on the XML, then it will try and match on Root node only, but again if you have more than one schema with the same root node, it will fail.
What you need to do is look at the suspended message and look at it's context properties and see what it's Message Type is, and compare that against the schema in BizTalk. There should be exactly one that matches.
vs
But to answer your question,
The source location is usually just the path of where the DLL was when it was initially imported in Dev.
the %BTAD_InstallDir% is the directory you chose when importing a MSI, the default location is C:\Program Files (x86)\Generated by BizTalk. However that is just where it puts it initially
Yes, in the end the actual one it uses will be in the GAC, which is under C:\Windows\Microsoft.NET\assembly\GAC_MSIL
Note: If the DLL has been previously been deployed and you are deploying a new one then make sure you restart the host instances afterwards, as it will cache DLLs in memory for a period.
I am using DNN 7.3 for a website project which is a combination of VB and C# codes. I use visual studio 2013 to build the project.
If the MSBuid Option in property page is configured to Allow this Precompiled site to be updatable and the project is published.
There will be a successful built. But when it is checked in to the TFS, the following exception will be thrown:
/compiled/DesktopModules/Admin/Security/manageusers.ascx (8): Circular file references are not allowed.
/compiled/DesktopModules/Admin/Security/manageusers.ascx (67): Unknown server tag 'dnn:profile'.
/compiled/DesktopModules/Admin/Security/EditUser.ascx (5): Circular file references are not allowed.
/compiled/DesktopModules/Admin/Security/EditUser.ascx (163): Unknown server tag 'dnn:Profile'.
/compiled/admin/Users/ViewProfile.ascx (4): Unknown server tag 'dnn:Profile'.
Also, when I checked Use Fixed Naming and Single Page Assemblies together with the Allow this Precompiled site to be updatable. it will throw:
ASPNETCOMPILER: Object reference not set to an instance of an object.
when I searched online, I was given two options from this blog.
I have tried the two but still having the same error.
I don't know what I am doing wrong.
Please look at [here] (http://ellisweb.net/2009/12/fixing-the-circular-file-references-are-not-allowed-error-in-asp-net/) for the explanation why you would see this error, simply speaking, if you have the following setup:
/folder1/Control1.ascx > References Control2
/folder2/Control2.ascx > References Control3
/folder1/Control3.ascx
This means that the folder1 dll will reference the folder2 dll which will again reference the folder1 dll, causing a “circular file reference”.
The solution is try to rearrange all controls under each folders, sometimes, you have to make a problem user control copied over to multiple folders to prevent such circular calling.
I changed The Clean WorkSpace property of TFS Build Process Parameters to false.
The error just disappeared and I was able to build successfully into TFS Drop folder. I don't know why this solves the problem but the problem was resolved.
The question is a follow up to this one: Generate Web.Debug config which could be debugged](Generate Web.Debug.config which could be debugged)
I have defined a transformation for web.debug.config. During compilation I see the following:
Transformed Web.config using C:\data\Main\WebRole\Web.Debug.config into
C:\data\Main\obj\obj\x64\Debug\WebRole.csproj\TransformWebConfig\ [...]
transformed\Web.config.
Checked Web.config in the specified location - it is correct (transformation succeeded)
But when I start the service in the azure emulator I get an alert that
Why does it happen? Looks that incorrect web.config is taken. Where should I specify the location of correct (transformed) file?
The key thing to realise with web.config Transforms (and is mentioned in the answer to your linked question) is that they are only part of the story.
When you build your sources, the transformed web.config file is built into the /obj/ folder, ready for deployment.
It is only the act of deploying your solution somewhere that puts the transformed config file into use - as noted in the docs:
When you deploy the Web application by using the selected build configuration and by using either a deployment package or one-click publish, the Web.config file is transformed according to your specifications.
How are you running the application after you build it? You need to publish or deploy it using one of the built in mechanisms that support web transforms to see those changes on your site.
If you are running the emulator against the original source files, they won't see the transformed web.config file - which is why typically the debug build doesn't have any transforms and you then turn off debugging with your Release build which is then deployed to production.
As you're trying to test this in the emulator you should be able to do the following:
In the Solution Explorer, ensure you've selected a file within the project that runs in the emulator.
From the Build menu, select "Publish [Project Name".
In the Publish Wizard, create a new "Profile" using the "Custom" publish target.
In the "Connection" pane select "File System" as the publish method, and give it a suitable target location.
In the "Settings" pane choose the appropriate configuration (in your case probably "Debug"), and set any other options that you'd like.
Then press "Publish", and the project should be built, and then deployed to the new file location.
You should then be able to start the emulator from this newly published location, which will be using your transformed web.config.
I have found this solution and it works perfectly
https://translate.google.co.il/translate?hl=en&sl=de&tl=en&u=http%3A%2F%2Fwww.sascha-dittmann.de%2Fpost%2FWebConfig-Transformation-im-Windows-Azure-Compute-Emulator.aspx&anno=2
I am using the TcmUploadAssembly utility in a post-build event but am receiving the following error from the tool.
Error 1 Name must be unique for items of type: Template Building Block
within this Folder and its BluePrint context. Source or sources of
conflict:
tcm:5-200-2048. C:\Projects\Project1\src\Tridion\TBBs\EXEC Compound
Templates
The TcmId given refers to the Assembly stored in Tridion which I would expect because that is what I am overwriting. In the past this "just worked". Am I missing something?
Notes:
My user is an admin
The Tridion instance is on my network so I am using credentials in context.
I have specified all settings via the command line (no config.xml is used)
Any ideas?
I would say check your Blueprint context (i.e. the Publication you are in). This error means you are trying to create the TBB, yet there is already an item with the same name probably somewhere down in the Blueprint child Publications.
Classic writing out the problem and the problem solves itself...
I discovered the folder is set in the AssemblyInfo as well and I had the folder set incorrectly on the command line (Blueprinting issue).
I ran into a second problem however, if I set uploadpdb:true on the command line I receive this error
Error 1 Could not write file: c:\Temp
Setting uploadpdb:false resolves the issue.
First of all sorry if the question is not very clear.
I am learning nHibernate from the summerofnhibernate.com, in the first chapter when I run a test project, I get the following error: Test method TestProject1.NHibernateDataProviderTestTest.CanGetCustomerByIdTest threw exception: NHibernate.HibernateException: problem parsing configuration : System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies;PrivateAssemblies\hibernate.cfg.xml'.
I have googled the problem, and the search says that the VS 2008 path is wrong(buggy), to place hibernate.cfg.xml in test project and adding the attribute: [TestMethod(), DeploymentItem("hibernate.cfg.xml")]
After having done this I still get the same problem.
But when I use Visual Studio 2010 I get the following error:
Test method TestProject1.NHibernateDataProviderTestTest.CanGetCustomerByIdTest threw exception:
System.NullReferenceException: Object reference not set to an instance of an object.
looks like 2 different problems.
For the first place nhibernate.cfg.xml in the Project and give the path to new Configuration("Path to hibernate.cfg.xml") somewhere in the testsetup.
The Second looks like the getmethod returns null because it cant finde the Customer with given id in the database. If you use SQLite inMemory a typical captcha is, that each new Connection points to a different Database -> Open Sessions with sf.OpenSession(theOneConnection) or Session.Clear() instead of creating a new one.
Hope it helps
Basically , (depends on your question : How to Configure Test Deployment with the file LocalTestRun.testrunconfig?)
Here is the way that you can follow:
To select files or folders to deploy, in run configuration
In Solution Explorer, under Solution Items, double-click the run configuration file that you want to edit.
A dialog box that has a name such as .testrunconfig appears.
Click Deployment.
Under Additional files or directories to deploy, specify additional files or folders to be copied.
To do this,
click Add file to select files; this opens the Add Deployment Files dialog box.
You can also click Add Directory to select folders by using the Add Deployment Directory dialog box.
In the .testrunconfig dialog box, click Save and then click OK.
These deployment items will be copied to the deployment folder whenever this run configuration file is active.
Hope this will help.