We are creating a new data warehouse using SSIS and are looking at BIML Studio. I know that for BIML Express I need Visual Studio, but for BIML Studio it seems that we don't even need Visual Studio if we develop our entire ETL with BIML Studio. Is this correct or do I still need Visual Studio in some way?
Standard consulting answer: "It depends"
Your BimlStudio workflow is probably going to be a few BimlScript files that contain your core logic. And then there's gonna be the generated artifacts. As an example, here's shot of the Logical view of my current Biml project. It's a large and still growing "export procs to fixed width files" solution for a client.
Since I need to write to a flat file, that means each package needs a Flat File Connection Manager and a Flat File Connection Manager needs a Flat File Format definition. So, 1 logical entity requires 3 Biml artifacts (at least for how I'm building it)
What you see in the BimlScripts and Connections folder are what run the project (plus the custom metadata repository aka "one big table").
The black circle next to 01_FFF.biml means that's a "live" Biml so every time I make a change to my metadata or the underlying file, whoosh out comes 45 File Format entries (project view)
All of this is great but eventually, I need to translate what's in my Integration Services node (1 project, 45 Packages) into a deliverable.
What's your deliverable?
Right clicking on the project gives me 3 options: Build, Build & Run, Build and & Open in SSDT
Build - this results in a .ispac file being created. That's the quantum for pushing a project deployment model into the SSISDB
Build & Run - Honestly, I don't know what this option does. I should check the book https://link.springer.com/book/10.1007/978-1-4842-3135-7
Build & Open in SSDT - This results in everything you need to interact with the project in Visual Studio (a .dtproj file, Project.params, any Project level .conmgr files and all the associated .dtsx files)
When would I need Visual Studio?
Debugging. I'm pretty good at this stuff but even I miss some settings for things I don't have solid patterns for. For example, this project is using Fixed Width File Formats and in early iterations, I was getting defects open as the files weren't correct because the default file encoding was for Unicode, despite each individual column being defined as DT_STR (non-unicode). Little stuff like that is much easier to find and resolve and fix back in BimlStudio. Otherwise, you're trying to debug the results of a package execution but if you knew you had the wrong pattern, you wouldn't have built the bug into your pattern.
I have a legacy code base which has CMake configuration and .sh files which calls build commands with respect to build type ( release, relwithdebinfo etc.) as well as does a lot of things.
I have to work over codebase. So far I used STM32CubeIDe. I imported the project as existing Makefile project and then I changed C/C++ Build directory to where makefile outputs converted.
So whenever I did a change on the code, I hit the build command over UI and it calls make command at where I modifed the path above.
This is working but In case of a need of debug then I had to use .elf outputs and OZONE J link Debug program.
I have to do build+debug in same environment but eclipse is slow and making me struggle.
How can I make VSCode host to my legacy code in order to build and debug and also navigate in code i.e go to the definition of code in VSCode, not only building.
Please navigate me if anything needs to share from existing code base, if there is still unclear.
I am looking to build a VSCode Extension around a CLI tool which we have been working on. An example command would be
myCLI retrieve SourceName
This would be run from a specific directory (for example c:/workspace/myproject) which has been setup and contains a settings.json file for some config arguments.
This CLI has been designed that the methods which are called (for example 'retrieve') are exposed directly so the CLI itself is a wrapper also.
When trying to call these methods directly from a VS Code Extension, it is always checking in the C:/Program Files/Microsoft VS Code directory, which I understand is where the Extension is excuting from.
Now, the question: Is there any way for me to force that any time we call the method (for example 'retrieve') that this would look into the current workspace folder (C:/workspace/myProject) , and not the VS Code one (C:/Program Files/Microsoft VS Code)?
Notes which may change answers
CommonJS (not yet ESM)
We currently cannot pass in a full qualified path (for example C:/workspace/myProject), it is only looking for ./settings.json since it depends on where the CLI has bene run from
I want to avoid calling the CLI directly, as I would like to bring many of the CLI features into the VS Code Extension directly to improve user friendliness.
I ran Protobuild.exe, but no one has mentioned where it outputs to. Does anyone here know where the default folder is suppose to be at?
Running Protobuild.exe generates the Visual Studio projects and solutions for every platform. The solutions are in the root directory, i.e. along Protobuild.exe.
Note that Protobuild does not build the framework - you have to open the solution and build it in Visual Studio (which generates its output in MonoGame.Framework\bin subdirectory).
I have a Visual Studio 2010 solution that contains a library of functions, and I would like to be able to use MATLAB as one of several possible front-ends to this library. Therefore, I would like Visual Studio to automatically generate a mex file when I build the solution, without having to export all my build options and paths to mexopts.bat and open MATLAB to build the file from there. I have seen several suggestions to achieve something similar, for example in these posts:
Matlab 7.1+ and Visual Studio 2005
Compiling a MEX file with Visual Studio
How to use CMake and Visual Studio 2010 (64 bit) to build a MATLAB R2011a (64 bit) mex file?
However, they either seem a bit outdated (making references to files that are no longer to be found) or make use of external tools (eg. CMake). Does anyone know how to set up a new project (within the existing solution) in Visual Studio (2010 and newer) that will build a mex file for contemporary MATLAB releases?
After some experimenting with guidance from this page mentioned in the question, it seems like starting with an empty C++ project the following settings in the project's Property Pages are necessary and sufficient to build a working .mexw64 from Visual Studio 2010:
Configuration properties -> General:
Set Target Extension to .mexw64
Set Configuration Type to Dynamic Library (.dll)
Configureation poperties -> VC++ Directories:
Add $(MATLAB_ROOT)\extern\include; to Include Directories
Configuration properties -> Linker -> General:
Add $(MATLAB_ROOT)\extern\lib\win64\microsoft; to Additional Library Directories
Configuration properties -> Linker -> Input:
Add libmx.lib;libmex.lib;libmat.lib; to Additional Dependencies
Configuration properties -> Linker -> Command Line:
Add /export:mexFunction to Additional Options
$(MATLAB_ROOT) is the path to Matlab's root folder, eg. C:\Program Files\MATLAB\R2013a.
So far this has only been tried from a solution created from scratch and built for Matlab 2013a 64-bit. I assume that to build for 32-bit one only needs to change both occurrences of 64 to 32. I will update the post when I have confirmed that this works for an existing solution.
EDIT: As expected this works for projects added to existing solutions. Remember to set the new project to be dependent on the project that creates the library.
Edit 2: Following this question I can confirm that the above steps work in Visual Studio 2012, 2013, and 2017 too.
Quickly Setting up Visual Studio Projects for MEX files with a Property Sheet
All of the settings can be applied via property sheets, a mechanism for rapidly applying Visual Studio project configurations.
Steps:
Download the property sheet (MATLAB.props) from this GitHib repo.
It's short and sweet. I'd actual urge you to make your own to learn what's involved in the process. See the Property Sheet Details section below for a description.
Set the MATLAB root environment variables: MATLAB_ROOT for your 64-bit MATLAB installation, and MATLAB32_ROOT for any 32-bit MATLAB installations (e.g. C:\Program Files\MATLAB\R2014b\). This folder has the subdirectories bin, extern, sys, etc. Restart VS if it's opened.
Create an empty DLL project in Visual Studio, optionally creating a x64 solution platform. Do this by choosing "Win32 Project" and selecting DLL as follows:
In "Property Manager" (select from the View menu), for each project's build configuration, right click and choose "Add Existing Property Sheet...", and select the appropriate property sheet (32 or 64 bit). (See screenshot below)
That's it!
Just remember that when going between MATLAB to use your MEX file and Visual Studio to build a new version, it will be necessary to run a clear mex or clear specificMEXFileName to be able to overwrite it.
I build almost all my MEX files this way.
UPDATE (05/22/15): The file MATLAB.props now supports the Parallel Computing Toolbox for using mxGPUArray objects. If the toolbox path and library (gpu.lib) exist on your machine, they can be used. Just include the CUDA SDK "Build Customization" (that should be installed if you've installed the CUDA SDK and installed the Visual Studio integrations) to include cuda_runtime.h, etc. Finally, link with cudart_static.lib (but keep Inherit... checked or you will get other linker errors).
Property Sheet Details
There are only a few important settings in the property sheet:
Adding $(MATLAB_ROOT)\extern\include to the AdditionalIncludeDirectories paths (with inherited paths from parent configurations) -- the location of mex.h.
Adding $(MATLAB_ROOT)\extern\lib\win64\microsoft to the AdditionalLibraryDirectories paths -- the location of libmex.lib, etc.
Listing the libraries: libut.lib;libmx.lib;libmex.lib;libmat.lib.
Exporting mexFunction (it's a shared library): /EXPORT:mexFunction.
Setting the output file extention (e.g. .mexw64 for x64).
Not necessary, but it also specifies an output manifest that is NOT embedded in the library, sets MATLAB_MEX_FILE, and turns on generation of data required for profiling.
For completeness, note that there is a more formal "build configuration" system for project configuration, which includes a property sheet, but a loose property sheet is sufficient for setting up a simple MEX project.
A Note About -largeArrayDims
The -largeArrayDims option is a switch to the mex command in MATLAB that simply indicates not to define MX_COMPAT_32. So, in Visual Studio, you don't have to do anything since this is not defined by default. If you want the opposite behavior (-compatibleArrayDims), then define MX_COMPAT_32 in the Preprocessor section.
What's libut.lib for?
I include libut.lib, which provides a few nice functions for detecting a break (CTRL-C) from within a MEX file. The relevant declarations (although this is getting off topic):
// prototype the break handling functions in libut (C library)
extern "C" bool utIsInterruptPending();
extern "C" void utSetInterruptPending(bool);
For building/linking/compiling, automate visual studio with an extension or macro to
start a thin Matlab client (using -nojvm -noawt -nodesktop -nosplash commandline options, this starts in less than a second on my machine)
generate the binary by calling mex (including the other dependencies etc).
if debugging is activated, attached the visual studio debugger to your newly started thin matlab client(any break points you click in VS will be active).
I have automated this for visual studio 2010. This way, you work with your mex-wrapper entirely from the visual studio IDE, have 4 extra pushbuttons for debugging etc. Compile errors are echoed from a matlab terminal window instead of within Visual Studio. Find the Macros uploaded here:
http://www.mathworks.se/matlabcentral/fileexchange/39549-visual-studio-toolbar-for-mex-interface-with-video-tutorial