It took far too long but I finally found this document on Migrating MSBuild-Integrated solutions to Automatic Package Restore and I was able to resolve the issue using the methods described here.
- Remove the
'.nuget'
solution directory along from the solution
- Remove all references to
nuget.targets
from your .csproj
or .vbproj
files. Though not officially supported, the document links to a PowerShell script if you have a lot of projects which need to be cleaned up. I manually edited mine by hand so I can't give any feedback regarding my experience with it.
When editing your files by hand, here's what you'll be looking for:
Solution File (.sln)
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = ".nuget", ".nuget", "{F4AEBB8B-A367-424E-8B14-F611C9667A85}"
ProjectSection(SolutionItems) = preProject
.nuget\NuGet.Config = .nuget\NuGet.Config
.nuget\NuGet.exe = .nuget\NuGet.exe
.nuget\NuGet.targets = .nuget\NuGet.targets
EndProjectSection
EndProject
Project File (.csproj / .vbproj)
<Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>
My first answer misunderstood the question completely, so let's try this again.
Your central problem is the free type parameter T
in the definition of doCallback
. As you point out in your question, there's no way to make a SWIG object out of a shared_ptr<T>
without a concrete value for T
: shared_ptr<T>
isn't really a type.
Thus I think that you have to specialize: for each concrete instantiation of doCallback
that the host system uses, provide a template specialization for the target type. With that done, you can generate a Python-friendly wrapping of data
, and pass it to your python function. The simplest technique for that is probably:
swigData = SWIG_NewPointerObj((void*)(data.get()), SWIGType_Whatever, 0);
...though this can only work if your Python function doesn't save its argument anywhere, as the shared_ptr
itself is not copied.
If you do need to retain a reference to data
, you'll need to use whatever mechanism SWIG usually uses to wrap shared_ptr
. If there's no special-case smart-pointer magic going on, it's probably something like:
pythonData = new shared_ptr<Whatever>(data);
swigData = SWIG_NewPointerObj(pythonData, SWIGType_shared_ptr_to_Whatever, 1);
Regardless, you then you have a Python-friendly SWIG object that's amenable to Py_BuildValue()
.
Hope this helps.
Best Answer
From reading this, you need to add the SQL Server Data Tools package.
https://social.msdn.microsoft.com/Forums/en-US/70e6b312-48b6-48f5-abc7-6400dfe8ad34/visual-studio-2015-enterprise-reporting-functionality-missing?forum=vssetup
We have managed to track down the solution to this issue. It turns out that the components required for reporting are located within the Microsoft SQL Server Data Tools package. In order to install this package, perform the following steps as a privileged (local or domain administrator) account. Ensure that Visual Studio and all related programs are closed before you begin.
Open Control Panel > Programs > Programs and Features, and select the entry for your version of Microsoft Visual Studio 2015. In our case, it was Microsoft Visual Studio Enterprise 2015. Click the "Change" button on the top bar above the program list. After the splash screen, a window will open. Press the "Modify" button. Select Windows and Web Development > Microsoft SQL Server Data Tools, and check the box next to it. Press the "Update" button on the lower-right hand side of the window. Once the installation is complete, open your version of Visual Studio. After the new .dll files are loaded, Reporting functionality should be reimplemented, and you should be able to access all related forms, controls, and objects. Our working theory is that the web installer did not install the required components for Reporting during the initial installation - however, the issue seems to be resolved now.