I developed an BizTalk orchestration where I am calling custom library method.
Since my custom library is consuming a web service and writing data into database therefore it reads various info like database connection string , WCF service endpoint address from appconfig. I put my custom library into GAC and deployed the BizTalk application but I am unable to find a place where I can put the appconfig which is used by custom library.
I Googled and found to append the config file in BTSNTSVc.exe placed under :\Program Files (x86)\Microsoft BizTalk Server 2013, however its not the recommended way.
You can save your configuration in BTSNTSvc.exe.config, but that file contains biztalk host configurations.
Take in mind, that if you'll have a syntax error in that config file - you'll have troubles running biztalk engine.
Best solution is to use a cache layer which you will consume by C# class library from your orchestration.
A better option is add to BTSNTSvc.exe.config a redirection to your config file, for example:
<appSettings>
<add key="myConfigFile" value="C:\MyProject\Config\myConfigFile.config" />
</appSettings>
This allows you to modify the configuration of your application without modify each time the BTSNTSvc.exe.config.
Related
I have a ASP.NET MVC application which uses EF (v6) as data access layer. My application works fine on IIS Express and also when deployed to the server running IIS 7.5.
The problem is that I'm getting the following exception when I deploy it to Azure (Web Sites).
Code generated using the T4 templates for Database First and Model First development may not work correctly if used in Code First mode. To continue using Database First or Model First ensure that the Entity Framework connection string is specified in the config file of executing application. To use these classes, that were generated from Database First or Model First, with Code First add any additional configuration using attributes or the DbModelBuilder API and then remove the code that throws this exception.
I've searched the web and I made sure my connection string starts with "metadata=" + checked my db context class' constructor to be sure it contains the correct name (in my case it's "name=PsDataEntities"))
My connection string looks like this: <add name="PsDataEntities" connectionString="metadata=res://*/PsDataModel.csdl|res://*/PsDataModel.ssdl|res://*/PsDataModel.msl;
provider=System.Data.SqlClient;
provider connection string="data source=SERVER_NAME;initial catalog=DB_NAME;user id=UID;password=PWD;
MultipleActiveResultSets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />
Anybody had the same problems?
Any help is appreciated
I did a few more tests (like changing metadata in the connection string to use fully qualified names instead of '*') without success, then I decided to set my metadata (regarding .csdl/.ssdl/.msl) programatically with the help from this post. Application now works correctly when deployed to Azure.
I have a WCF service that will serve multiple clients. I'm using ent lib for the logging.
I'd like to have a different log file for each client. is there a way to change the file name back and forth?
I found a few threads but they all talk about editing the config file during runtime.
ALso found this: Enterprise Library Logging but it talks about environment variables. I will set the log name according to the client id.
Thanks
Avi
You can have distinct categories linked to individually configured FlatFile or RollingFile tracelisteners for each client.
If filenames are unknown till runtime, consider using fluent API for configuration, like so:
http://msdn.microsoft.com/en-us/library/ff664363(PandP.50).aspx#fluent_api_logging
I have a WCF service which uses Entity Frameworks to connect to a database, all hosted in a Windows Service. The problem is that when the first message is handled to cause a database access, an exception is thrown: "Unable to resolve assembly 'MyService.exe'". Basically, when running as a windows service EF can't locate the embedded resources.
I've checked for the presence of the 3 resources, csdl, ssdl, msl using .Net Reflector in the static exe and they're there. I'm using this connection string
metadata=res:// MyService.exe/MyModel.csdl|
res:// MyService.exe/MyModel.ssdl|
res://MyService.exe/MyModel.msl; provider=...".
I added code to the Windows Service to enumerate the embedded resources in the OnStart method when the service is started (using GetExecutingAssembly(). GetManifestResourceNames()), and it shows nothing there. [of course, the win svc is installed/run with installutil + net start]. When I run a nearly identical project, linking to all the same sources including the app.config, as an interactive console app (different Main() of course), everything works fine, including the enumeration of the resources (all 3 edmx mapping files are there). The Win Svc is running under Local System.
Has anyone else had difficulties using EF in a windows service? Any ideas about whats going wrong or how to diagnose/fix it?
Try replacing "MyService.exe" with "*" like this:
<add name="MyEntities" connectionString="metadata=res://*/MyModel.csdl|res://*/MyModel.ssdl|res://*/MyModel.msl;provider=System.Data.SqlClient;provider connection string="data source=.\sqlexpress;initial catalog=DatabaseName;integrated security=True;multipleactiveresultsets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />
Is it possible to specify a relative connection string for an AzMan XML store?
My current connection string is connectionString="msxml://c:/azman.xml" but I really need to make that relative so other developers and automated builds can get the latest authorization store.
MS documentation seems to suggest that connectionString="msxml://azman.xml" should work but that throws a The request is not supported error.
EDIT: I realised that the fact I'm using AzMan through the Enterprise Library Security Application Block was important to the question.
It is possible to enter the token {currentPath} into the connection string used by the security application block.
This gave me the behavior I was after, allowing the AzMan.xml file to be accessed from with the application folder.
The connection string I am using is:
<authorizationProviders>
<add storeLocation="msxml://{currentPath}/azman.xml"
application="My_Application" scope="" auditIdentifierPrefix="AzMan Authorization Provider"
type="Microsoft.Practices.EnterpriseLibrary.Security.AzMan.AzManAuthorizationProvider, Microsoft.Practices.EnterpriseLibrary.Security.AzMan, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
name="AzMan Provider" />
</authorizationProviders>
Adding the ~ will make it relative to the application
<add name="AuthorizationServices" connectionString="msxml://~/App_Data/AzMan.xml"/>
If you use {currentPath}, be sure your current directory is properly set before you make the "AuthorizationFactory.GetAuthorizationProvider" call. I am also using the Enterprise Library Security Application Block.
Ex.
My.Computer.FileSystem.CurrentDirectory = HttpContext.Current.Request.PhysicalApplicationPath
I have the httphandler on shared webhosting.
It works.
The httphandler webapp (virtual) dir of this httphandler does not have web.config
and the whole shared user's website has web.config with only one uncommented statement:
<compilation defaultLanguage="c#" debug="false"/>
Now, I change it to:
<system.web>
<urlMappings enabled="true">
<add url="~/CheckLoad" mappedUrl="~/BackupLicense.ashx?key=CheckLoad"/>
<compilation defaultLanguage="c#" debug="false">
</compilation>
</system.web>
This(*) works locally (on VS2008 internal webserver)
but not on shared hosting.
What do I miss?
(*) means calling [1a], which works only locally but on shared hosting it gives
"The page not found" "HTTP Error 404"
[1a] Calling as:
http://www.MySharedSite.com/CheckLoad
(additionally to always and evertwhere working
[1b] http://www.MySharedSite.com/BackupLicense.ashx?key=CheckLoad
There are some subtle differences in how URL's are handled on the built-in webserver and on IIS6 and 7. You need to know the version of IIS running on your shared host.
Specifically, IIS6 does not support URL's without the extension being mapped to aspnet_isapi.dll - and since you are not using an extension for the URL, this could be the case.
If your host is using IIS7 with integrated pipeline mode, you propably need to configure the system.webServer section with your url mapping, instead of system.web. (Also, see this question for an explanation of the difference).
Edit
I see in the comments your webhost is using IIS6. Then you need to ask your webhost to allow the /Checkload URL to be processed by ASP .NET. Another easy way to make it work would be to just use .ashx on the end of the url; since the .ashx extension is already mapped to ASP .NET in the standard configuration.