I know the drill - Choose Items - point to the dll - voilà!
But there are some attributes on the pipeline component. Does these affect the visibility? And how to change these?
<ComponentCategory(CategoryTypes.CATID_PipelineComponent), _
ComponentCategory(CategoryTypes.CATID_Any), _
ComponentCategory(CategoryTypes.CATID_Validate), _
System.Runtime.InteropServices.Guid("E7C186DF-D5DD-46a0-90A4-A2A6804763B0")>
ublic Class clsComponent
Implements IBaseComponent, Microsoft.BizTalk.Component.Interop.IComponent, IPersistPropertyBag, IComponentUI
I know this is an old post, but according to Microsoft, here is what you need to do:
http://msdn.microsoft.com/en-us/library/aa577482(v=bts.20).aspx
All the .NET pipeline component assemblies (native and custom) must be located in the \Pipeline Components folder to be executed by the server. If the pipeline with a custom component will be deployed across several servers, the component's binaries must be present in the specified folder on every server.
You do not need to add a custom pipeline component to be used by the BizTalk Runtime to the Global Assembly Cache (GAC).
Custom COM components in the pipeline will also appear in the Toolbox, provided they are registered on the computer as a COM component. Custom .NET pipeline components must be placed into the \Pipeline Components folder.
After the binary files are in the correct location, you need to add the component to the Toolbox. For instructions on adding the pipeline component to the Toolbox, see How to Use the Toolbox.
If I understand your question correctly, you've written a custom PL component, are trying to add it to your custom PL, have gone to choose from the Choose Items tool box and its not appearing?
These might be obvious but double check that you've performed the following steps;
a) GAC'd the PL Componet Assembly.
b) Copied the PL Component DLL to the BizTalk Install Location\Pipeline Components folder.
c) Closed and Re-started your PL Solution.
You should now be able to see your Custom PL Component in the Choose Items Box.
HTH
Related
Using the base Exrin template, I am unable to use custom controls.
As it stands now, the Droid/iOS projects reference the App/Bootstrapper project, so that seems like the correct place to put them, but when creating a new page or BaseView, I am not able to access the custom control's namespace because the View project does not reference the App/Bootstrapper project.
The Tesla sample app does not have this problem in its current implementation since there is no separation of the App/Bootstrapper and the View projects.
(1) Should a reference to the App/Bootstrapper be placed in the View project or (2) should a reference to the View project be placed in the Android/iOS/etc projects? Or is there a better solution than either of these two?
Edit:
(1) does not work because a reference to the App project from the View would create a circular dependency.
(2) should work (I think), but I'm having trouble getting the Application.Droid project to access the Application.View project namespace because when I add using Application.View;, the namespace isn't found in the Application namespace. Visual Studio attempts to fill in other Application namespaces (.Container, .Logic, .Droid, .Proxy) when I type in using Application.
The native project can have a reference to the View. It already does in a way, because it references the App library, which then references the View. Hence you aren't really adding any further dependencies by doing this, just allowing access further up the chain.
If you are having trouble the namespace, I suggest you start out with
global::Application.
That way it starts from the top, if its getting mixed up with project namespaces.
I have a complete ASP.NET project and am now trying to use automatic testing methods to test the code.
So, I have calls to methods which use configurationManager to call settings from Web.config for things like API keys etc..
My question is, it possible to synchronise my app.config for my test project and my web.config, so that if I update either one of them it takes effect on both projects, or will I have to do something different?
I have currently just copied what I need from the web.config, but because I work for a website we always have changing variables and I can't guarantee that if we change one that my colleagues will remember to update the corresponding key in both projects.
In the unit test project properties, you can add a pre-build step to copy the main web.config to the unit test project, overwriting the existing unit test project config file. This will do the same as you do now manually, but gaurantees the two config files will be in sync.
Alternatively, and perhaps better, delete the existing unit test config file (and exclude from the project) the click 'Add Existing Item' within the unit test project, choose the main project config file, and select 'Add As Link' instead of 'Add' (click the right hand edge of the 'add' button to achieve this). There will only be one config file on your disc, but both projects will use it.
When I deploy my applications I notice a very strange behaviour – Not all binding files are imported as they should be while others are.
I'm using a custom pipeline component that promotes a set of properties to the context, some are defined at in the pipeline itself while others are defined in the BTS Admin console so we can define them in the binding files.
<ReceivePipelineData><Root xmlns:xsd="http://www.w3.org/2001/XMLSchema" … Components><Component Name="I.MMA.COMPONENT"><Properties ><Customer vt="8">CUSTOMER_NAME</Customer>< … etc.
This works fine for some of our applications, they are being well deployed and our values that are configured in the binding file are visible in the admin portal while other applications don’t show the same information and the strange part is that, when we generate the binding files for the failing applications, the values are in the binding file but not visible nor used by BTS.
I have this behavior on different machines, anybody got an idea what is going on?
I recently moved my pipeline component from one stage to another while I didn't update the Stage CategoryId and the values were ignored.
I've seen something similar and fixed it by manually re-entering the pipeline settings in the admin console. I suspect that if the binding file settings are not exactly what the console expects for the pipeline then it doesn't display them. So try re-entering the settings for the affected ports and update your binding files from that.
I have some basic questions related to publishing.
If I have a component A which has a multimedia link to Component B.
When I publish component A using a dynamic CT, the component B will also be published.
Will component B's custom meta-data also get published? (I couldn't locate the custom meta-data in transport package for component B)
If I unpublish component A, It will also unpublish component B? But what if component B is linked and published with several other components?
If I insert a component on a page using a dynamic CT, after publishing, will the component Presentation get added to database, or as a static part on page or at both locations? (We use file system for pages and broker DB for dynamic CPs)
I know these are basic questions, but these will solve several doubts. thanks.
If I have a component A which has a multimedia link to Component B. When I publish component A using a dynamic CT, the component B will also be published.
This is not true. To publish multimedia links you have to use <img src="tcmid" ..... /> for your multimedia link to be published and your CT needs to include Default Finish Actions which contains Publish Binaries in package.
Typically When you publish Component A, it will only publish multimedia file (img,jpg,pdf etc) when you have above line of code in your DWT and you have the TBBs mentioned above.
Q # 1 : In this case metadata will not be published since you are just publishing the multimedia file via code
Q # 2 : Multimedia File will not unpublished when you unpublish Component A if it is being used or referenced. Tridion Deployer checks if there are any references to the multimedia file and deletes the file only if it does not have any references.
Q # 3 : Publishing to databasse or filesystem is not just based on simply Dynamic CT. It is based on your storage configuration on your deployer side. It based on what you configure in the storage either to db DB or FS.
If you want to publish Multimedia Components dynamically you need a Dynamic CT associated with that Multimedia Schema (OR) You could write a C# TBB as part of your Dynamic CT of the same for Component A and publish dynamically via code.
Here is Tridion documentation you can also check, may not be straight forward answers to your questions, but will provide some additional information.
http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/concept_56BCD7B2A1994C76B940751B2458D8E0
I am newbie in .net.Today I have created a sample. In that sample, I have stored data in database using N Tier architecture. If I want to use to Use BL or DAL method in other project(I mean BL method in UI or DAL method in BL), I found two ways.
First one is - Right click on project << Add Reference << Select Project in Project tab
Second one is - Right click on project << Add Reference << Select DLL in Browse tab
Could anyone tell me that is there any difference between both of them as both works same.Is DLL way better then Project Reference.If yes, then what is the benefits?
Thanks in advance.
Regards,
Mohit Kumar.
The correct way to do it is to add a project reference.
one of the most important differences is that a project reference is updated automatically when you change the referenced project.
for example- If you change your DAL method from GetEmployees() to GetAllEmployees() then you can use GetAllEmployees() immediately in your BL class, without compiling your DAL first.
You typically use the project reference when the reference is part of your solution. In this way the relevant latest code is always used.
You will reference an assembly when it is a third party component or not part of your solution. This is somewhat more static as you will be using the code at the version represented by the assembly. So any changes to the assembly will require you to physically overwrite the referenced assembly with the updated dll.
HTH
The differences between the 2 have already been answered, however just to add to that, I think the only difference between the 2 in VS is that if you add project reference it still adds a normal dll reference, except the reference is to the Debug location of the projects binaries (i.e. bin\debug\project.dll), so in essence you could probably just Add Reference in the same way and point straight to the latest compiled dll.
I have came across a very interesting difference between the two approaches, but in the context of having 2 projects, one shared among multiple developers and one private to each developer.
Let us say that the shared VS project is called projectS, and the private project is called projectP
Now if the objective is to have a centralized development, and the developer needs to access source definitions from both projectP and projectS so that pressing "F12" or "Go To Definition" in VS would bring complete definition, then we have to use the Project Reference and not the DLL reference, otherwise pressing F12 would bring the definition from the compiled "metadata" excluding all developer comments and other relevant data.
When adding a Project Reference to projectS from within projectP, VS will resolve references to the files included in projectS and referred to from projectP using the source definition in projectS, and not from "metadata" of the DLL associated with the referenced project (ProjectS.dll). Still, the projectS.dll will be included in the References folder and Development time, Execution time will be OK.
When adding a DLL reference, VS will resolve references from "metadata" stored in ProjectS.dll, even if the Referenced Project was added to the Solution of projectP as an "Existing Project". This would allow Execution time to be OK, however, Developer will not be able to press F12 and go to Source definition in projectS, he/she will have to do this manually from the solution search area.