SubSonic 3 Regenerate ActiveRecord Class Automatically? - activerecord

I have a SQLite database and SubSonic3, finally got a clue on how to generate the .cs from the .tt in Visual Studio. My stuff builds now.
I can kick off MSBuild automatically to build my project, but I would like to add a pre-build event to regen the ActiveRecord.cs cleanly so any database changes end up there for future Unit tests.
How can I simulate the 'run external tool' in the Visual Studio GUI?
Thanks.

You can run the TextTemplating tool from the command line:
C:\Program Files\Common Files\Microsoft Shared\TextTemplating\1.2\TextTransform.exe "path/to/your/ttfile.tt" -out <outFileName>
Use TextTransform.exe /help for more command line arguments you can use.

At this time, the SubSonic's Settings.ttinclude file must be run from within the VisualStudio application, and can not be run from the command line. This is because Settings.ttinclude uses the project context to locate the App.config / Web.config file so that it can look up the connection string.
Attempting to run via command line using TextTransform.exe will result in the error:
error : Running transformation: System.InvalidCastException: Unable to cast object of type 'Microsoft.VisualStudio.TextTemplating.CommandLine.CommandLineHost' to type 'System.IServiceProvider'.
This stems from this method in Settings.ttinclude:
public EnvDTE.Project GetCurrentProject() {
IServiceProvider _ServiceProvider = (IServiceProvider)Host;
...
}

By hacking the Settings.ttinclude file, you can set up Subsonic to run from the command line.
Just modify it to set your connection string as the return value of GetConnectionString and taking out all other logic.

Related

OpenDDS - Solution builds fine, examples run, but IDL exes crash

I have successfully built OpenDDS 3.13.2 from source. Here is my environment:
Windows 10
Visual Studio 2017 (re-targeted Solution to SDK 10.0.17763.0)
Tried all Configuration/Platform combinations
I successfully used the configure script from the VS command prompt, built everything by opening the generated solution in the same command prompt, and finally ran the Messenger example (publisher and subscriber), and even configured it to use RTPS successfully.
However, when I try to create my own IDL and use the tao_idl, it crashes. Here's my test (using the proper environment from setenv.cmd):
> tao_idl (no args)
IDL: No input files
Second test:
> tao_idl Test.idl (crashes)
I get no error message, and am unable to locate logs or any indication of what went wrong. The same thing happens when I used opendds_idl.
What is the best approach to debug this, and/or are there pre-built binaries available for the IDL compiler(s) (both TAO and OpenDDS)?
After about a day of troubleshooting, I have determined a solution. Despite being able to call tao_idl and opendds_idl yourself, you should basically never do it. There are a good amount of command-line arguments needed to get both to work, and if they're not present, each exe will crash without the proper reasoning why.
I will add my steps below to create a new basic two-exe pub/sub project using OpenDDS:
Create your own IDL file.
Starting with the DCPS Messenger example, modify the .mpc file, replacing Messenger.idl with your IDL file name.
Create a new file called <your project>.mwc, and add the following contents:
workspace {
// the -relative and -include cmdlines make it so this workspace
// does not have to be in the $DDS_ROOT directory tree.
// tell MPC to substitute our DDS_ROOT environment variables for relative paths
cmdline += -relative DDS_ROOT=$DDS_ROOT
// tell the projects where to find the DDS base projects (*.mpb)
cmdline += -include $DDS_ROOT/MPC/config
}
Open a new VS command-line terminal and run $DDS_ROOT/setenv.cmd, or open a regular terminal if you have those environment variables set via Windows settings.
Navigate to your project directory and call: mwc.pl -type vs2017, replacing "vs2017" as needed for your build tool/IDE.
Open up the generated solution, and retarget it as necessary for your Windows SDK version.
Build the <your project>_IDL project first. If you notice in the output window, it is invoking the tao_idl and opendds_idl commands automatically. You can view the .vcxproj files to see the full command-line arguments that were the original problem.
Modify the publisher.cpp, subscriber.cpp, and DataReaderListenerImpl.cpp files to match your new IDL. Run the example as usual and ta-da!
For completeness, the full commands for both tao_idl and opendds_idl are as follows:
> opendds_idl -Sa -St "<your file>.idl"
> tao_idl -Wb,pre_include=ace/pre.h -Wb,post_include=ace/post.h -I$(TAO_ROOT) -Sa -St -I$(DDS_ROOT) "<your file>.idl"
> tao_idl -Wb,pre_include=ace/pre.h -Wb,post_include=ace/post.h -I$(TAO_ROOT) -Sa -St -I$(DDS_ROOT) "<your file>TypeSupport.idl"

Trying to Add a Reference to Visual Studio Project Suddenly Throws an Exception

When I try to ADD a REFERENCE to any Visual Studio project...I am suddenly getting the following exception:
Error HRESULT E_FAIL has been returned from a call to a COM component
This happens across ALL projects regardless of whether they are source-controlled (or not)
SIDE NOTE:
I did recently install Xamarin on a SEPARATE PROJECT in another TFS SOLUTION
WHAT I'VE DONE SO FAR:
Delete all *.suo files
Delete all *.user files
Wiped the TFS Workspace & done a FORCE GET
Nothing has worked
The FIRST TIME you get this error message you'll get a window with a reference to the following file:
ActivityLog.xml: This file contains information about the underlying error.
If you ignore the message & click away from the initial dialog, THE ERROR GETS SUPPRESSED and is replaced with:
Error HRESULT E_FAIL has been returned from a call to a COM component.
If you look in this file you will see the error. This particular exception was was caused by:
Microsoft.visualstudio.shell.interop.IVsReferenceManager2
Within the Microsoft.VisualStudio.Shell.Interop.11.0.dll library.
This post helped me solve the issue!
THE FIX IS:
Open "Developer Command Prompt for VS 2017" as an Administraor
CD into "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\PublicAssemblies"
Run "gacutil -i Microsoft.VisualStudio.Shell.Interop.11.0.dll"
After a restart, it all worked well.

When running mstest under OpenCover, I get an error regarding the .vsmdi.trx file

I am having a problem when trying to run a VS10 test suite through OpenCover, using mstest as my target application.
Running the tests directly with MsTest works with this command:
"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe" /resultsfile:"<application_root_path>\UnitTestResults\MyProject.vsmdi.trx" /testmetadata:"MyProject.vsmdi" /testlist:"ServiceTests" /testlist:"DatabaseTests"
However, when trying to run the same command under OpenCover, like this:
OpenCover\Opencover.console.exe -register:user -target:"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe" -targetargs:"/resultsfile:"<application_root_path>\UnitTestResults\MyProject.vsmdi.trx" /testmetadata:"MyProject.vsmdi" /testlist:"ServiceTests" /testlist:"DatabaseTests"" -output:<application_root_path>\UnitTestResults\Coverage
it fails, with the following error, regarding the .vsmdi.trx file (which I gather should be created by MsTest after the tests run):
Error occurred while loading document '<application_root_path>\UnitTestResults\MyProject.vsmdi.trx'.
Code: 0x800c0006
The system cannot locate the object specified.
So, basically, it complains that it cannot find the results file, before running the tests, but that file is supposed to be created at the end of the run.
Might this be an issue related to OpenCover, as the same params work when running directly with mstest?
I checked my paths and they all work out, even the one in the error is the path where the file should be generated by mstest.
Thanks.
It looks like you may need to escape your quotes when passing your data via targetargs
-targetargs:"/resultsfile:"<application...""
becomes
-targetargs:"/resultsfile:\"<application...\""
as detailed in the wiki on handling spaces.
Alternatively put your command to execute your tests in a cmd/bat file and then use opencover to execute that.

Running a generic test after a successful build using vs and TFS 2010

I'm using team explorer under vs2010 to queue a build that is configured to run an automated test after the build. The automated test section is configured to use a vsmdi file that defines one testlist with one generic test that only opens calc.exe.
Looking in the log, after the successful build, mstest generates the following error log and calc is not running on the build agent:
Run MSTest for Metadata File
The MSTestActivity was invoked without a value for Platform or Flavor. The values Mixed Platforms and Debug were used.
C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe /nologo /usestderr /searchpathroot:"C:\Builds\4\CITest\CI_AUT_1\Binaries" /resultsfileroot:"C:\Builds\4\CITest\CI_AUT_1\TestResults" /testmetadata:"C:\Builds\4\CITest\CI_AUT_1\Sources\AUT1.vsmdi" /testlist:"TestList1" /publish:"http://vmftrnd70.devlab.ad:8080/tfs/QTPCollection" /publishbuild:"vstfs:///Build/Build/82" /teamproject:"CITest" /platform:"Mixed Platforms" /flavor:"Debug"
Loading C:\Builds\4\CITest\CI_AUT_1\Sources\AUT1.vsmdi...
Search path(s) for tests:
C:\Builds\4\CITest\CI_AUT_1\Binaries
C:\Builds\4\CITest\CI_AUT_1\Sources
Search path(s) for default test settings:
C:\Builds\4\CITest\CI_AUT_1\Sources
Failed to load tests from 'C:\Builds\4\CITest\CI_AUT_1\Binaries\generictest1.generictest': Microsoft.VisualStudio.TestTools.TestManagement.InvalidStorageExtensionException: File extension specified '.generictest' is not a valid test extension.
at Microsoft.VisualStudio.TestTools.TestManagement.Tmi.GetTestTypeInfosForExtension(String ext)
at Microsoft.VisualStudio.TestTools.TestManagement.Tmi.GetTestTypesNotManagedInStorage(String storage)
at Microsoft.VisualStudio.TestTools.TestManagement.Tmi.LoadTestsFromTipsHelper(IEnumerable`1 locations, ProjectData projectData)
at Microsoft.VisualStudio.TestTools.TestManagement.Tmi.LoadTests(IEnumerable`1 locations, ProjectData projectData, TestConflictHandler vetoingHandler)
at Microsoft.VisualStudio.TestTools.TestManagement.Tmi.LoadTests(String location, ProjectData projectData, TestConflictHandler vetoingHandler)
at Microsoft.VisualStudio.TestTools.TestManagement.Tmi.LoadTestLinkStorageHelper.LoadTests(String fullStoragePath, ProjectData projectData)
at Microsoft.VisualStudio.TestTools.TestManagement.Tmi.SimpleLoadTestLinkStorageHelper.Load(String fullStoragePath, ProjectData projectData)
Starting execution...
Test GenericTest1 cannot be found.
No tests to execute.
I've tried all possible ways to get the generic test to run after the build with no success...
Nothing about this on msdn\google,
Thank you for any clue you can think of.
You need full Visual Studio installed to recognise the filetype
I haven't used generic tests myself, but from the msdn documentation it looks like they have to be treated as test containers.
In your build definition, change the process to use a test container and use ***.generictest instead of ***test*.dll and see if that works.
As a note, if you are firing up a GUI tool like calc.exe, then your build server will need to be running interactively otherwise you'll have test failures.

"Source" parameter of the "MIDL" task. Multiple items cannot be passed into a parameter of type "Microsoft.Build.Framework.ITaskItem"

I am trying to migrate one of projects earlier in VS2008 to VS2010. On building I get the following error
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(317,7): error MSB4094: "hdxBinding.idl;hdxBlinking.idl;HDXCommandObject.idl;hdxds.idl;HSCProcessStatus.idl;HSCSelectableWindow.idl" is an invalid value for the "Source" parameter of the "MIDL" task. Multiple items cannot be passed into a parameter of type "Microsoft.Build.Framework.ITaskItem".
On clicking this error, it takes me to the line Source ="#(Midl)" inside C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets file
A Code Snippet in Microsoft.CppCommon.targets file:
<ItemGroup>
<Midl Condition="'#(Midl)' != ''">
<MinimalRebuildFromTracking Condition="'$(BuildType)' != 'Build' or '$(ForceRebuild)' == 'true'">false</MinimalRebuildFromTracking>
</Midl>
</ItemGroup>
<PropertyGroup>
<MidlToolArchitecture Condition="'$(MidlToolArchitecture)' == ''">$(DefaultToolArchitecture)</MidlToolArchitecture>
</PropertyGroup>
<MIDL
Condition ="'%(Midl.ExcludedFromBuild)'!='true'"
Source ="#(Midl)"
AdditionalIncludeDirectories ="%(Midl.AdditionalIncludeDirectories)"
AdditionalOptions ="%(Midl.AdditionalOptions)"
ApplicationConfigurationMode ="%(Midl.ApplicationConfigurationMode)"
ClientStubFile ="%(Midl.ClientStubFile)"
CPreprocessOptions ="%(Midl.CPreprocessOptions)"
DefaultCharType ="%(Midl.DefaultCharType)"
DllDataFileName ="%(Midl.DllDataFileName)"
EnableErrorChecks ="%(Midl.EnableErrorChecks)"
ErrorCheckAllocations ="%(Midl.ErrorCheckAllocations)"
ErrorCheckBounds ="%(Midl.ErrorCheckBounds)"
ErrorCheckEnumRange ="%(Midl.ErrorCheckEnumRange)"
ErrorCheckRefPointers ="%(Midl.ErrorCheckRefPointers)"
ErrorCheckStubData ="%(Midl.ErrorCheckStubData)"
ExcludedInputPaths ="$(ExcludePath)"
GenerateClientFiles ="%(Midl.GenerateClientFiles)"
GenerateServerFiles ="%(Midl.GenerateServerFiles)"
GenerateStublessProxies ="%(Midl.GenerateStublessProxies)"
GenerateTypeLibrary ="%(Midl.GenerateTypeLibrary)"
HeaderFileName ="%(Midl.HeaderFileName)"
IgnoreStandardIncludePath ="%(Midl.IgnoreStandardIncludePath)"
InterfaceIdentifierFileName ="%(Midl.InterfaceIdentifierFileName)"
LocaleID ="%(Midl.LocaleID)"
MkTypLibCompatible ="%(Midl.MkTypLibCompatible)"
OutputDirectory ="%(Midl.OutputDirectory)"
PreprocessorDefinitions ="%(Midl.PreprocessorDefinitions)"
ProxyFileName ="%(Midl.ProxyFileName)"
RedirectOutputAndErrors ="%(Midl.RedirectOutputAndErrors)"
ServerStubFile ="%(Midl.ServerStubFile)"
StructMemberAlignment ="%(Midl.StructMemberAlignment)"
SuppressCompilerWarnings ="%(Midl.SuppressCompilerWarnings)"
SuppressStartupBanner ="%(Midl.SuppressStartupBanner)"
TargetEnvironment ="%(Midl.TargetEnvironment)"
TypeLibFormat ="%(Midl.TypeLibFormat)"
TypeLibraryName ="%(Midl.TypeLibraryName)"
UndefinePreprocessorDefinitions ="%(Midl.UndefinePreprocessorDefinitions)"
ValidateAllParameters ="%(Midl.ValidateAllParameters)"
WarnAsError ="%(Midl.WarnAsError)"
WarningLevel ="%(Midl.WarningLevel)"
TrackerLogDirectory ="%(Midl.TrackerLogDirectory)"
MinimalRebuildFromTracking ="%(Midl.MinimalRebuildFromTracking)"
ToolArchitecture ="$(MidlToolArchitecture)"
TrackerFrameworkPath ="$(MidlTrackerFrameworkPath)"
TrackerSdkPath ="$(MidlTrackerSdkPath)"
TLogReadFiles ="#(MIDLTLogReadFiles)"
TLogWriteFiles ="#(MIDLTLogWriteFiles)"
ToolExe ="$(MIDLToolExe)"
ToolPath ="$(MIDLToolPath)"
TrackFileAccess ="$(TrackFileAccess)"
AcceptableNonZeroExitCodes ="%(Midl.AcceptableNonZeroExitCodes)"
YieldDuringToolExecution ="$(MidlYieldDuringToolExecution)"
>
</MIDL>
Can somebody please tell me whats going wrong here. This is driving me crazy!!!!!!
Got a similar error today on a project that I am converting to VS2010. I don't have a good solution to the problem yet, but I have a workaround. In my case, the project contained 2 idl files. Call them A.idl and B.idl. A.idl is the main idl for the project. It includes B.Idl. The error I received was:
error MSB4094: "A.idl;B.idl" is an invalid value for the "Source" parameter of the "MIDL" task. Multiple items cannot be passed into a parameter of type "Microsoft.Build.Framework.ITaskItem".
It seems that the build system searched for all idl files in the project and made a single call to the MIDL compiler with all of them even though that was bound to fail. I don't know why VS2010 does that and earlier version didn't (or maybe earlier versions of MIDL could handle multiple inputs).
The workaround: grab the MIDL arguments off of MIDL Command Line page of the project's properties. Then run MIDL by hand in a VS2010 Command Prompt window using those args. In my case, since A.idl includes B.idl, I only needed to run one MIDL command:
MIDL options-copied-from-project-properties A.IDL
It looks like you have multiple idl files in your project (hdxBinding.idl, hdxBlinking.idl, etc.). So the same trick might work for you.
Good luck
I ran into this issue trying to build the DataMonitor example from the TMG SDK with Visual Studio 2010. The problem from what I can tell is the MIDL > Output settings in the project - the Header File, IID File, Proxy File, and Type Library were set to "DataMonitor...", which was forcing those settings to be applied to all included IDL files (and not just the project's generated one).
Changing those settings to use %(Filename) instead and the project built fine.
When there are multiple IDL files in the project I converted from VS 2008 to VS 2010, I got this error. Since one IDL I had was included in the other. I disabled building of the included IDL file and it resolved this error.
These errors prop up when migrating to VS2010 as the .idl file properties are not migrated by VS2010 migrator. I got a similar error and resolved this by manually adding these parameters from to VS2010. Once done you will be able to get rid of these build errors.
I run into the same problem as well. The fix was (very confusing) remove empty in the vcxproj file. I run out of time and have not got to the bottom of why it helps - defining not empty HeaderFileName fixes the problem as well, other empty elements do not cause this problem (e.g. DllDataFileName).
If you want to reproduce bug or process of my investigation just create hello world and add two idl files. It should work. However if you add ItemGroupDefinition with Midl.HeaderFileName it should start failing. One wild guess is that it has something to do with batching of tasks (working example calls MIDL task for each file separately).

Resources