I am looking for an XML to Excel Pipeline. I have tried so many of them. even tried to create my own. Is there any sample available that I can start working on?
The best way, if you have the time and the knowhow is to roll your own Excel pipeline Component.
In order to get you started, install this into Visual Studio (there are other versions of it depending on BTS version, this one is for BTS 2013 R2):
http://www.quicklearn.com/blog/2014/09/20/biztalk-server-2013-r2-pipeline-component-wizard/
The wizard will write the boilerplate code for you and will leave you to concentrate on the actual conversion. I'd recommend using some library to generate the Excel itself in order to get a valid, native, Excel file as output, for example EPPlus (http://epplus.codeplex.com/).
Once it's created, GAC:ed and put in the Pipeline Components folder, add it to your send pipeline in the "Encode" step.
Related
This may be a stupid question and/or a futile effort -- you've been warned...
I have a ASP .NET application (with the VB parts compiled to a DLL). This application has been around a while and the person who wrote it apparently messed up the old source code repository system. He is no longer around and I'm not clear on whether the source code I was given was a re-write or an older version (or by some strange luck the actual version of the website running).
Being that part of this website is running as a DLL, what is the best way I can go about in determining if the version of the source code I have matches what is running? I'm unable to setup an IIS server to throw this on (licensing/server cost/time/etc).
Is there a better way than compiling the project and then finding some disassembler and doing a comparison?
Is there a better way than compiling the project and then finding some disassembler and doing a comparison?
That's what I've done in the past in your situation.
Open each compiled assembly using ILSpy, and use the option "File / Save Code" to generate source files.
Build the source code from your source code repository, and use ILSpy to generate source files.
Compare the results of 1 and 2.
Obviously this won't give you the whole picture - you'll also need to compare aspx files, config files, ..., but it's the only approach I know.
I'm maintaining a webforms application for several different clients in Visual Studio 2008. Each client has their own separate web.config file. We are using config transformation when deploying which works great.
There are many developers currently working on this project, and while developing each developer needs to have the configuration values for a specific client. Right now, what we are doing is that each one of us, has their own version of web.config locally, and we just try to be careful not to check in the web.config file.
This approach of course has several drawbacks. We need to do this manually, which is annoying, we need to be really careful not to check in the config files since it could cause trouble for the rest of the developers, it's cumbersome to add a new value to the config, etc.
I'd like to transform the config files when building from visual studio, so we can chose which file to take the configuration values from, without having to manually edit web.config.
I've been looking in the web for a while, but the best thing i found so far is this:
http://www.codeproject.com/Articles/399002/Project-Build-Web-config-transformation
Which is not working for me, it gives me a build error saying it can't copy Web.config_output because the file is missing.
By default tools like SlowCheetah and other config transform technologies use the $(Configuration) to figure out the name of the transformation to apply. You could take the slowcheetah.targets file and edit it to take $(username) which will pick up the standard windows logged on user name if you're building inside visual studio. You could use a condition to apply the change specifically when '$(BuildingInsideVisualStudio)'='true'.
This will require you to do some work with MsBuild target files, but the end result would be that your developers can check in a web.jesse.houwing.config (in my case) and that of that file is there, their transformation will be applied instead of the standard release or debug transformation.
As for a good starting point, look at SlowCheetah.
I have several Visual Studio 2008 projects (ASP.NET 3.5) with many local resource files for localization of strings found in specific ASP.NET pages. Some of them are grouped in folders, some are named based on the page they are localizing, etc.
For example, App_LocalResources folder has a list of .resx files matching ASPX pages, UserControls/App_LocalResources matching ASCX user controls, etc.
Now I need to translate the application to another language and I would like to send all those keys for translation to someone who doesn't have access to the Visual Studio projects.
I could always write a small console app which would recursively find all .resx files and combine them to one big custom XML file which I could then send for translation. Upon receiving the translated XML file, the console app would recreate all small .resx files.
This all isn't a problem, but there must be a better way. What would you suggest, how should I do it?
I'm currently adding .NET support to appTranslator to .NET. The tool helps you easily manage translations of your resources by letting translators work on a single localization project file and creating the satellite DLLs right-away from the translations. I'll let you know when it's ready.
Passolo will automatically extract the default resource strings from exe's and dll's to a "bundle" that you can pass to a translation firm.
We are doing this at my work and it seems to work quite well.
You can exclude/hide strings to translate, add comments for each string and have multiple languages in the same project/bundle.
=======================
This Visual Studio Add in helps extract individual strings to resource files (.resx)
http://resourcerefactoring.codeplex.com/
Resource Refactoring Tool provides developers an easy way to extract hard coded strings from the code to resource files.
Its says its only been developed for VS 2005/2008 but it will be updated for vs 2010 soon.
Write a shell script for extracting all files into an excel. After extracting into excel any can easily manipulate it easily or write a tool for converting resource files to excel.
For Reference:http://www.codeproject.com/Articles/20920/NET-Resource-File-to-Excel-File-Converter
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.
In my automated NAnt build we have a step that generates a lot of code off of the database (using SubSonic) and the code is separated into folders that match the schema name in the database. For example:
/generated-code
/dbo
SomeTable.cs
OtherTable.cs
/abc
Customer.cs
Order.cs
The schema names are there to isolate the generated classes that an app will need. For example, there is an ABC app, that will pull in the generated code from this central folder. I'm doing that on a pre-build event, like this:
del /F /Q $(ProjectDir)Entities\generated*.cs
copy $(ProjectDir)....\generated-code\abc*.cs $(ProjectDir)Entities\generated*.cs
So on every build, the Nant script runs the generator which puts all the code into a central holding place, then it kicks off the solution build... which includes pre-build events for each of the projects that need their generated classes.
So here's the friction I'm seeing:
1) Each new app needs to setup this pre-build event. It kind of sucks to have to do this.
2) In our build server we don't generate code, so I actually have an IF $(ConfigurationName) == "Debug" before each of those commands, so it doens't happen for release builds
3) Sometimes the commands fail, which fails our local build. It will fail if:
- there is no generated code yet (just setting up a new project, no database yet)
- there is no existing code in the directory (first build)
usually these are minor fixes and we've just hacked our way to getting a new project or a new machine up and running with the build, but it's preventing me from my 1-click-build Nirvana.
So I'd like to hear suggestions on how to improve this where it's a bit more durable. Maybe move the copying of the code into the application folders into the NAnt script? This seems kind of backwards to me, but I'm willing to listen to arguments for it.
OK, fire away :)
How often does your DB schema change? Wouldn't it be possible to generate the database-related files on demand (e.g. when the schema changes) and then check them into your code repository?
If your database schema doesn't change, you can also package the compiled *.cs classes and distribute the archive to other projects.
We have two projects in our solution that are built completely out of generated code. Basically, we run the code generator .exe as a post-build step for another project and along with generating the code, it automates the active instance of visual studio to make sure that the generated project is in the solution, that it has all of the generated code files, and that they are checked out/added to TFS as necessary.
It very rarely flakes out during the VS automation stage, and we have to run it "by hand" but that's usually only if you have several instances of VS open with >1 instance of the solution open and it can't figure out which one it's supposed to automate.
Our solution and process are such that the generation should always be done and correct before our auto-build gets to it, so this approach might not work for you.
Yeah I'd like to take VS out of the equation so that a build from VS is just simply compiling the code and references.
I can manage the NAnt script... I'm just wondering if people have advice around having 1 NAnt script, or possibly one for each project which can push the code into the projects rather than being pulled.
This does mean that you have to opt-in to generate code.