Creating a SharePoint package is easy enough with Visual Studio but each time you restart it, the package location used previously is replaced with the default location of the current user’s Documents folder.
To save a few seconds from my life I decided to write a PowerShell script to build and package the solution, meaning I no longer have to specify the publish location whenever Visual Studio is restarted.
I’m using Visual Studio 2013 and SharePoint 2013
& "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe" "C:\Projects\TestProject\TestSolution.csproj" /t:rebuild;package
Write-Host "Copying TestSolution.wsp to Packages folder" -NoNewLine
Copy-Item -Confirm:$false "C:\Projects\TestProject\bin\Debug\TestSolution.wsp" C:\Packages\
Write-Host " - done."
The script shown has been simplified for this post and is easy enough to parametrise to allow you to specify different SharePoint projects to package.
Anyway, back to the main reason for this post.
After doing the above and running the script the following error was generated:
C:\Projects\TestProject\TestSolution.csproj(88,3): error MSB4019: The imported project “C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets” was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
When working with a LINQ to SQL model (dbml) and you try to add a custom stored procedure that uses dynamic SQL, you will likely see an error similar to the following:
The return type for the following stored procedure could not be detected. Set the return type for each stored procedure in the Properties window.
Visual Studio will detect dynamic SQL as the return type of a stored procedure when you return columns from temporary tables, for example.
How to resolve? Relatively easy actually. At the start of your stored procedure, add the following line:
SET FMTONLY OFF
Update the procedure to include the above command and back in Visual Studio, refresh your database connection before trying to add the procedure to the model. This time, Visual Studio is able to work out the return columns and their type. Once you’ve added it to the model, remove the command from the stored procedure in SQL.
What does setting FMTONLY to off do? Well, while this set to off, running the procedure only returns the metadata, no rows are returned. By doing this Visual Studio is able to determine the columns. Simple! 🙂
If you use the database schema compare tool in Visual Studio 2012 you may see the following error when trying to compare the database with the source:
Cannot access a disposed object. Object name: ‘ModelStore’
For me, this was arose after installing the June 2013 update 3 for Visual Studio 2012.
I resolved the error by running Clean Solution and rebooting my machine.
Hopefully this helps someone, as the error isn’t exactly helpful 🙂