SSIS (SQL 2005) packages that have a script task that invoke custom .NET dlls throw the following error when run in a 64 bit environment
The task cannot execute in 64-bit environment because the script is not pre-compiled. Please turn on the option to pre-compile the script in the task editor.
The script tasks are set to PreCompile=false because the referenced dll is generated by the build process.
The suggested workaround is:
Option 1. With precompiled=True, Open, save and close the package in BIDS after the build is complete
. This will recompile the reference and generate the embedded 64 bit binary in the SSIS package and will cause the above mentioned error to go away. However, this also means that someone has to manually open the SSIS packages after the build is complete.
Option 2. Stick to 32 bit mode.
Option 1 is the feasible one of the two, but impractical. With 200 SSIS packages - we are short of hands to finish this task every time we generate the build.
Option 2 is out of the question because 32 bit just doesn't scale for us.
Now the questions:
1. Do you folks have a build process for your SSIS packages? If yes, can you share your practices
2. How do you manage script tasks? Are you comfortable bundling the developer version of the referenced dll in your scripts?
This is probably not what you want to hear,but i would suggest exploring the idea of replacing some of your script tasks with custom components. There are plently of samples on codeplex. This would allow easy updates because you would just drop new component builds and the referenced assemblies into GAC.
HTH
Pragmatic Works has something (I have never used) called BI xPress which has something which might help.
Related
It appears that building ISPAC using MSBuild is near impossible. I'm hoping I can find a way to create ISPACs in the VSTS build processes, but it doesnt appear to be straight forward.
there is a VSTS task by ToxicGlobe
https://github.com/ToxicGlobe/VSTS-SSIS-Extension
However support seems minimum, and there isnt alot of traction.
how does the real world create ISPACs in a common CI process?
There isn’t such build-in task available in VSTS, but you can refer to the source code of VSTS-SSIS-Extension to custom the build/release task to meet your requirement through VSTS extension: Add a build task
I use this command:
devenv SolutionName.sln /Rebuild
In the Bin folder of the project, you are going to find the .ispac file, Remember to include the path of devenv.exe in the System Variable "Path"
I have this project from github, database on sales and inventory system. But when I open it, it encounters errors.
I really need help on how to open this project with no errors? What should I do to fix this project?
PS: Need a step by step explanation regarding this, I just started databases, so I'm not sure what other tools I should be needing like MS Access or SQL.
The error is self-explanatory: underlined data types cannot be found.
That's means these types are defined in assemblies, currently not available to the compiler.
So in order to build the solution you need to supply these assemblies. There are multiple options, but I'd recommend doing this through NuGet as it is fully automated(you know about it, right?).
The missing assembly is related to the Microsoft.Reporting. So install this and try to build again.
I often find the quote "InstallUtil.exe" is an ugly pattern or "Don't use InstallUtil.exe" and that I should use native WIX or Installation package patterns and I still don't understood why.
I stepped away from using InstallUtil to install a .NET service as I finally learnt that writing registry keys for such an action should be an un-install-able action - and I've come to terms with this as correct.
As I've been working through my WIX installer for a relatively complex product, I have found myself in need of creating or updating SQL Server databases, creating or updating IIS Applications and finally updating or creating configuration files.
Each of my components (features) are optional, but they all share the same configuration file. As my product uses unity, its important to note that this library contains strong support for reading/updating/removing components from the Unity Configuration block, therefore it seems fairly smart to me that I should take advantages of these blocks via Installation Components (i.e. InstallUtil) to create or update my configuration file at installation time.
Just to be clear here, my installer does not natively contain a configuration file for my application: at installation time, the installer has no idea as to the shape of it as its based on the features selected. Surely I should be embedding this knowledge into each of the modules that are to be deployed and not in the remit of the installer which is now a completely independent project? Wouldn't this break O-O principals even if we are talking about installation?
I'd really appreciate some guidance as to whether this is good practise or not? Am I reading 'InstallUtil' is bad for installing services, or is it that using 'InstallUtil' is bad full-stop? If so, what are my options for smart updating of configuration files?
The main reason for avoiding InstallUtil is that it runs outside of the installation transaction, so Windows Installer cannot keep track of what it's done.
I have used InstallUtil on a few occasions, when I just couldn't get Wix to do what I needed and didn't have time to write a custom action. In this case I called the InstallUtilLib version as I feel this is a cleaner approach.
I used the this blog as a guide as to how to achieve this.
I am using Visual Studio 2008 to build my projects.
I often take existing sample code and edit it and toy around with it, as I am just learning and I'd like to advance my skill.. it's nice to have a template to work with.
That being said, I often get the build error "Post build event failed". This is often accompanied by a "could not find xxx.sbr file" or something. I do not know what an sbr file is, not a "post-build event". Re-building doesn't seem to help, and clearing all the files out before tying another build does not help either.
That being said, the executable still always gets built.
I was wondering:
What is a post build event and what are the implications/causes of its failure?
What is an sbr file? I tried researching this a bit.. a "Source Browse File"? This site seemed pretty informative: http://www.ehow.com/facts_5657521_file-extension-sbr_.html
The problem is, I don't understand why the compiler would complain about not finding this (isn't it supposed to MAKE this?) and what EXACTLY it does ("enables Microsoft Visual Studio to access your source code" - can't it do this anyway?)
Thanks!
R
post build event is just a command you can have visual studio run after it's finished - maybe to kick off tests or build an installer.
It's in properties->build events in the menu - right click on the project.
The SBR file is used by visual studio to browse sources and lookup which function is in which file. I have had problems where somehow it's internal list of dependencies gets screwed up and it always rebuilds one of them.
Try a clean and rebuild, then try quitting visual studio and deleting the .ncb file
I'm using the Crystal Reports Viewer 11 ActiveX control in an Access form (version 2007, 2003 format). Everything works well on my development machine, where I have CRXI installed. I copied the referenced DLL to the client's machine, but when I try to register it, it says "Can't find module" (I double- and triple-checked my spelling) and when I try to open the form it tells me "ActiveX component can't create object" when the code tries to create a new instance of the report object. I suspect there are more dependency files required by the DLL, but I'm a little at a loss as to what ones and how I go about finding out. Although I'm using the CR control, I assume this would apply to any ActiveX control throwing this error. Thanks.
There should be a runtime distribution document in your Crystal Help files - from past experience (Crystal 8.5) there are multiple files that you have to distribute and register.
I'm answering my own question in case someone finds this via a search in the future. I don't have the Access Package & Deploy wizard David mentioned above (okay, I probably have it but couldn't find it readily) but I image it would probably do what I needed, so I recommend anyone try that first. Instead, I was able to create a setup to install tghe needed files using the Visual Studio Installer and the Crystal merge modules; note that while it wasn't difficult, nor was it pleasant.
I downloaded and installed Visual Studio Installer 1.1 from MSDN. This creates a new project type in Visual Studio 6.0 (in particular, I used InterDev 6.0) that creates a Windows Installer (*.msi) setup file. Because one of the Crystal merge modules requires the Crystal license key and VSI doesn't support merge module parameters, I also had to use Orca, a merge module editor, available from the Microsoft Windows SDK (also available on the Microsoft download site). I recommend reading through the SDK and Orca pages on MSDN for more info. Using Orca, I was able to put my key code and recompile the merge module, so I don't have to deploy my key to my users, and my users don't have to enter one.
Again, the Package & Deployment Wizard is probably a better option, but when faced with using merge modules, as with Crystal, this method will get the job done.