Setting DAQmx Tasks up in project instead of NI Max

Question

I am writing a labview application to be installed on a PC as an executable file with the Labview Engine.  I can put my DAQmx tasks in my project or NI Max.  If I put them in my project and I build my application, do I lose the ability to change the IO settings in NI Max independent of my application?
What is the best way to mechanize this with all the features of things like DAQmx tasks being created in my project rather than NI MAX? 

Answer 1

id wrote:
I am writing a labview application to be installed on a PC as an executable file with the Labview Engine.  I can put my DAQmx tasks in my project or NI Max.  If I put them in my project and I build my application, do I lose the ability to change the IO settings in NI Max independent of my application?
What is the best way to mechanize this with all the features of things like DAQmx tasks being created in my project rather than NI MAX? 
First. Yes persaisting the DAQmx features to the project removes them from MAX.  You will not be able to run them or modifiy them from MAX but only within the Project Context.
This is not always BAD.  For instance, no one can "Fat Finger" your configuration or install another Task with the same name that uses different settings.  Using the Project provides a context boundary wheras MAX is universally accessable.
Using the Project to store "Tasks, Scales, etc" DOES NOT remove the ability to modify them though.  Tasks stored in projects built into an EXEs wind up deployed as a text file in the exes support directory (Exe\Support\NI DAQ\<Something.txt>  This is a human readable configuration file that has the tasks settings in it.  If you need to change a setting (like increase a sample rate or change a physical channel) you can edit the file and the exe will use the new settings.
This is not always GOOD For instance, if the test system suffers a fault, MAX cannot selectively control the IO channels for troubleshooting.
Knowing the pros and cons of each method will help you work within your team to develop the best approach for your needs.  I've recommended each approach to various clients.  (And been right both ways!) 
What I've never recommended is creating tasks programatically.  However, I can see some use cases where hiding the configuration from everyone (on a removed BD) might be desired in a highly regulated enviornment where a possible change to a Task Property Could change code validation and the ECO process requires removing any possible "Hidden" access to the config files (Although a hash on the EXE folder could be used to disable testing)
Jeff