I have a solution where my Sagas and hosting are defined in two seperate projects:
Project NSB
=> Defines class CreateAuthoritySetSaga : SqlSaga<...>
Project Webhost
=> References project NSB
Webhost assemblyfile defines the PromotionSqlScript generation:
[assembly: NServiceBus.Persistence.Sql.SqlPersistenceSettings(
MsSqlServerScripts = true,
ScriptPromotionPath = "$(SolutionDir)PromotedSqlScripts")]
But when I build the solution, only SQL scripts for "baseline" NServiceBus tables are created (Outbox, Subscription, Timeout). The folder for sagas is empty.
This question Unable to host an NServiceBus Saga from another Service with SQL Persistence suggest to collect SQL output from the separate projects. But isn't there a way to instruct NServiceBus.Persistence.Sql.MSBuild which assemblies to look for sagas?
The scripts should be generated when your assembly that contains your saga is build. It should use the strategy as mentioned in the other post
See the documentation: https://docs.particular.net/persistence/sql/controlling-script-generation
Earlier a suggestion was mentioned to use "NServiceBus.Persistence.Sql.ScriptBuilder", but this package is not intended for public use!
Related
I have been trying to find out the differences between EntityFramework.Core and EntityFramework.MicrosoftSqlServer to figure out which one of the packages I need. I did not notice until today that in my Visual Studio solution, which has both a WebUI project and DataAccess project, that the WebUI only includes EntityFramework.MicrosoftSqlServer while the DataAccess project only includes EntityFramework.Core.
What is the real difference between the two and when should I include one vs. the other vs. both? I am using ASP.Net 5 Core for the entire solution.
EntityFramework.MicrosoftSqlServer depends on EntityFramework.Relational which in turn depends on EntityFramework.Core. Restoring the project is about creating the dependency graph and installing all required packages (regardless of whether they were specified in your project.json or not) into the project.
In your case you specified just EntityFramework.MicrosoftSqlServer but during restore the other dependencies (including EntityFramework.Core) will be pulled so it is not necessary to specify EntityFramework.Core explicitly.
If you are on dnx you can see the dependency graph using dnu list (you can use the --details flag to see even more details) or, if you are brave, you can take a look at the project.lock.json file.
Both are required but if you add EntityFramework.MicrosoftSqlServer then EntityFramework.Core will be added for you as it is a required by EntityFramework.MicrosoftSqlServer.
EntityFramework.Core contains all of the core code of EntityFramework such as DbContext, DbSet and any IQueryable extensions aswell as alot of other internal code.
EntityFramework.MicrosoftSqlServer contains the database specific sql syntax and connection code for sql server. There are other database providers available.
Available database providers:
EntityFramework.InMemory (this is good for writing tests that dont need a database)
EntityFramework.Sqlite
EntityFramework.MicrosoftSqlServer
I have 2 projects that reference the X12_00401_214.xsd. I was getting the message about duplicate schemas in the send pipeline.
Following advice I found online I create a common project and changed the map and orchestration references to the schema in the common project.
When I try to deploy the project, biztalk removes the schemas and orchestration from the other deployed EDI 214 project. If I try to redeploy to fix it, it removes them from the other project.
Is this because each project references the same common schema and biztalk is replacing the schemas and orchestrations?
I have tried redoing the orchestrations to make sure the variables were unique.
Is there a step I am missing here?
I finally traced the issue to the reference to the shared project. I had it referenced as a project reference. On each projected deploy it rebuild and deployed the shared project. This caused biztalk to drop the binding and undeploy the parts of the other project that referenced the shared project.
When I changed the project to reference only the compiled DLL, I no longer had the issue and both projects are now working.
I have 2 projects that reference the X12_00401_214.xsd. I was getting
the message about duplicate schemas in the send pipeline.
XMLNS#Root combinations of schemas must be unique. You are right that it is annoying that duplicates can be deployed and this error is only detected at run time.
Is this because each project references the same common schema and
biztalk is replacing the schemas and orchestrations?
I believe you may be adding your common schemas project to both your dependent EDI BizTalk applications. In this case, the schemas assembly will be added to the Resources of both projects, and you will have issues such as above.
The general advice here is to move common artifacts like shared or framework schemas, envelopes, pipelines, and possibly standard Exception Handling orchs etc into one or more separate BizTalk Applications (e.g. EDICommon) and define an application dependency on this from your 2 EDI Applications. There is an in depth article here. (There is no need for a BizTalk application to have any orchs or actually do any processing - it can just be a container for artifacts).
One caveat - you will need to uninstall all dependent Apps if your common schemas App changes significantly and you need to redeploy.
I'm writing a WCF service which is going to be used extensively within our company, and I'd like to generate WCF client proxies as part of the build process and package them within an assembly so that clients of the service don't have to repeat this process on their end numerous times. Is there any way that anybody knows of to accomplish this ? Are there any pre-existing build tasks for MSBuild ?
I was trying to solve the same problem. Here's what ended up doing.
In the .csproj, under AfterBuild target, add a task to fetch the SDK path, and use the Exec command to run the svcutil.exe. I had to use " because the path contains spaces.
<Target Name="AfterBuild">
<GetFrameworkSdkPath>
<Output TaskParameter="Path" PropertyName="SdkPath"/>
</GetFrameworkSdkPath>
<Exec Command=""$(SdkPath)bin\NETFX 4.5.1 Tools\svcutil.exe" $(TargetPath)"/>
</Target>
Here's what I wound up doing:
1) Create the project that has the service for which I want to generate client code
2) Create an MSBuild task that does the following:
a) Takes the compiled WCF Service assembly, runs svcutil.exe on it to extract XSD and WSDL metadata for all the services in the Service assembly.
b) Runs svcutil.exe again, this time on the extracted XSD and WSDL files to generate a .cs file containing the client
c) Run csc.exe to compile the generated client code into a separate assembly.
3) Insert the MSBuild task into the 'AfterBuild' target of the project containing the service.
Now every time I build the service, I get an automatically generated assembly that contains the client code that multiple other projects in our company can reference, without having to re/generate the same Web Reference in multiple projects. They can just reference a single assembly, and update more easily, having only to update one line in a project file rather than multiple files generated by the web reference generator. If anybody's interested, I can send them the code for the MSBuild task and the XML snippet for using it.
I am not aware of any built-in tasks, this is how I do it:
Create a project, generate the proxy class via svcutil and add it to the project.
Create an MSBuild script that (1) calls svcutil and overwrites the above class and (2) builds the project.
Would that not achieve what you want?
Look at T4 templating, and projects such as T4Toolbox
Why not simply create a separate, class library project. In that project, use "Add Service Reference" for each of the services you need.
Other code can then simply use the classes in the class library.
In our WCF solution we have one ConsoleHost (console application not class library) project and one WasHost Project. We use the Consolehost hosting for Dev environment and WAS hosting for production.
Now there are a number of .config files that are included using "include uri=file://services.config" in the Castle section of ConsoleHost project. I don't want to make a copy of this services.config file in the WasHost Project.
Is there a way to include files from other projects without making local copies of them? Or happy to hear other better ways of doing this.
Thanks
Ravi
You could do this a couple of ways.
One is to simply add a link to the source file from both projects as described here.
Alternatively you could embed the config into one of the common assemblies (Build Action=Embedded Resource in the file properties) and then use Castle's ability to include embedded resources. E.g.
<include uri="assembly://AssemblyName/xxx.config"/>
This call
// this._cfg is an NHibernate Configuration instance
this._sessionFactory = this._cfg.BuildSessionFactory();
Gives me this exception at runtime (NOT at compile time).
Could not load file or assembly 'NHibernate.ByteCode.Castle' or one of its dependencies. The system cannot find the file specified.":"NHibernate.ByteCode.Castle
OK so far. But the thing is, this code is running in a class library project, and I have referenced NHibernate.ByteCode.Castle (along with all the other NHibernate dll's) in that project.
Wierder: I can fix the exception by additionally referencing the NHibernate dll's in the Windows WPF executable project that calls my class library. But the Windows WPF executable contains no code that directly uses NHibernate (as evidenced by: It compiles fine without any NHibernate references). So what's going on? Apparently it's insufficient to reference NHibernate.ByteCode.Castle in the project that actually uses the NHibernate stuff. Anyone know why?
I know this is old, but what I've done to fix the dependency problem is simple:
In my UnitOfWork I added one static method:
private static void bringCastleDamnit()
{
var pf = new NHibernate.ByteCode.Castle.ProxyFactoryFactory();
}
Then, and only then, would MSBuild see that it was needed and copy it to my output directory for my (asp.net and console) apps that references my Data project.
I wouldn't reference the castle byte code factory at all; just ensure it (and all other needed dependancies) are copied to the output directory using a post-build step.