I have a pipeline that I need to reuse. I need to be able to chose this pipeline from any app as I can with the XML or the Passthrough pipelines.
Is there a way to publish a pipeline to the Microsoft.BizTalk.DefaultPipelines namespace?
Look like you have the asnwer but I want to clarify a couple of things.
As you're discovered, BizTalk.System is a readonly system Application and cannot be modified.
The .Net namespace Microsoft.BizTalk.DefaultPipelines actually has nothing to do with it.
For all your shared components, you would create a new Application container in BizTalk Administrator called "My Shared Components" or such.
Then Add Reference to this Application to make Pipelines and Maps deployer there available in the local Application.
Final point, Add Reference only affects the visibility of Pipelines and Maps in BT Admin Port Configurations. Any other GAC'd components are available by the standard .Net rules.
Off the top of my head, can't you deploy (add resource) to BizTalk.System?
Related
I am using Visual Studio 2010 and I am trying to create a solution containing an N tier architecture.
I have a project each for every tier
Common
DAL
Business //
Service // WCF
ServiceHost
Web
the projects are listed above are also called in the same order as well; so Web talks to Service tier, service tier talks to Business and business then talks to factory and factory project is responsible for talking to DB.
the issue I am having is to setup my projects in a way that before Web project is launched by pressing F5 - ServiceHost (which is just a self host console for WCF) should be started first so when Web calls for a service; it is up and running already.
Note: in PRD; Web and WCF will be hosted on different boxes altogether so this wont be an issue but for developing on Local machine - I need the above.
Interim Solution - I have excluded ServiceHost Project from the solution so it doesnt get launched with Web and I am running the ServiceHost executable externally from command line to get the Service up and running and then I am launching the Web project as normal using F5.
Can someone please tell me what do I have to do to achieve the above?
As Rajesh suggested, you set multiple projects to start in a multi-project solution. To do this, select DEBUG -> Set Startup Projects (or right-click on the solution and select Set Startup Projects... from the context menu.
This will give you a window that lists all your projects in the solution. Check the "Multiple startup projects" radio button, and set the Action column to "Start" or "Start without debugging" for each project you want to run. You can use the up and down arrows to specify the order.
If your web application requires the service to be available when it starts (i.e., the web site calls the service during it's initialization/startup), you may be better off doing as you are now (running the WCF service from the command line), otherwise this should get you where you want to be.
Attached is a screenshot (VS 2012) with a solution similar to the one you outlined above:
Since 2011sp1 Tridion comes with a precompiled core service client. Would there still be a reason to generate your own proxy by adding a service reference? Or is that older method officially deprecated now?
Let's take a look at advantages of compiled dll vs service reference:
Core service is growing and it's quite a problem to generate service reference reference on slower network. The bigger core service will be the harder it will be to generate service reference (there are workarounds of course)
Compiled dll is compiled using "correct" settings. There are some options you can set when generating service reference, like return types and types to be reused from other assemblies. By using compiled dll you are sure that you get everything right.
You can get quite a mess with you app.config when updating service reference. I think updating dll and config is a bit easier.
It's tricky to generate service reference when you have LDAP or SSO or HTTPs configured
The precompiled coreservice client is distributed by default to help implementers. As generating the own proxy is bit difficult (you might need to change some config in svcutil).
The precompiled coreservice client always uses the latest endpoint. Depending upon your situation you might need to generate your own proxy if you want to connect with the old endpoint always.
Otherwise you can use the precompiled client which will make sure you are connecting to the latest endpoint but that might break your client (you might need to fix something or recompile).
I have a fully functional wcf service where I can perform CRUD operations using jQuery on the client. I want this small service application to be portable so I am trying to avoid any app or web.config settings (e.g. Specific address endpoints). I have compiled my service application into a small dll file and have tried it in several different projects hosted at various web addresses. Everything works fine.
The only setting I put in the web.config file was for aspNetCompatibilityEnabled because I am using forms authentication. I did not define a name or a namespace for my service contract and my app.config file is empty sans a connectionstring. When I type in the address to my .svc file I get the 'endpoint not found error'. However my service is fully functional when I use the UriTemplates I defined in my operation contracts. What are the ramifications of this?
I don't care about exposing my data objects or methods on the .svc file. I just need this service to be portable and not blow up due to some unforeseen error.
Cautiously optimistic.
UPDATE
After further investigation it appears my example above is the default behavior for WCF. There is a good article from MS that explains it here.
I'm not sure what do you mean by portable. Your service is in dll, which can be used in any web application. Then it depends on your version of .NET Framework.
In .NET 3.5 you have to host the service in .svc file and configure it (service, endpoints, behaviors, AspNetCompatibility) in configuration file or in code.
In .NET 4.0 you can take advantage of simplyfied configuration model which can create endpoints for you based on other provided information. You can host the service in .svc file, by configuration based activation or by service route. In all cases it is important to use WebServiceHostFactory to allow automatic creation of endpoint using WebHttpBinding. You only need to configure AspNetCompatibility. If you need to futher specify webHttp behavior you can place it also in configuration without specifying behavior's name. Such behavior will be taken as default for all services (also not possible in .NET 3.5).
In neither case you don't need to configure base address because it is always taken from hosting web application.
While consuming a web service in my application I have two choices(ref. msdn)
Adding the Proxy Using the WSDL Tool
2.Adding the Proxy Using a Web Reference in Visual Studio
Now what should I choose, 2nd option is very simple and I generally follow that.
I want to know what are the pros and cons of both the options(if any) and ideally what should I choose?
Thanks.
They essentially achieve the same thing. The second gets the WSDL from the web service and generates the proxy, which requires the service to be online at the time.
Add the reference automaticly when possible, Visual Studio will do everything for you.
Under certain scenarios this is not possible. so you will have to do some manual work, like running the command to generate the proxy class and copying some configuration lines into the web.config manually.
I have a component (an assembly built in .net) that i need to access on (almost) every request to two different websites. One website is written in classic asp and the other one in asp.net mvc.
At the moment i reference the assembly in the asp.net solution and call it like i would any .net assembly. On the classic asp website, i call it through a COM wrapper.
This is all good, except now i need this component to actually stay alive and monitor changes to a configuration file. In my asp.net website i could keep a refence in the application scope and i guess i could register it in component services for the asp access.
Is this the best way to do it? Also, this way the component would actually be hosted twice - one instance in the asp.net application scope and one in the component services. I could perhaps instead only have it live in component services, and then instead reference it from asp.net.
I don't know - something smells fishy (and no, it's not me) - am i on the right track or do you see better alternatives?
Do you really need a long running object? You say you need to monitor configuration file changes -- when the config changes do you need to trigger some actions or do you just need to ensure that each incoming request uses the latest copy of the configuration for your component? If it is the latter then standard .NET configuration should work for you without concern for the object lifetime.
In terms of hosting, do you need to use any COM+ services? If not, then I would not use COM+. If you want one central location for your .NET component, why not register it in the GAC?
Ok so i think i found two solutions, both acceptable for this project:
1) Register it in global.asa on the Application_OnStart in the Application object like this Application("Someobject") = Server.CreateObject("Someobject")
2) Host it in component services and handle lifetime there.