I want to build a .sqlproj inside a linux container. The problem is that building the .sqlproj is dependent on SSDT and so far I can't find SSDT that can be installed as standalone on linux.
Error I see running 'dotnet msbuild' in my container:
error MSB4019: The imported project "/usr/share/dotnet/sdk/2.2.402/Microsoft/VisualStudio/v11.0/SSDT/Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Searching the .sqlproj file for the issue, I see we are trying to import a Schema.SqlTasks.targets file, which I'm assuming SSDT creates:
<Import Condition="'$(SQLDBExtensionsRefPath)' == ''" Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" />
I see the same error testing out 'dotnet build'
There is a Windows standalone option:
https://learn.microsoft.com/en-us/sql/ssdt/download-sql-server-data-tools-ssdt?redirectedfrom=MSDN&view=sql-server-ver15
https://www.nuget.org/packages/Microsoft.Data.Tools.Msbuild/10.0.61804.210
Has anyone found a way to provide SSDT in a linux container?
Goal State: The build step to generate the dacpacs would occur inside the container.
Current State: For now I'm using Visual Studio on my machine as the build machine, then copying the dacpacs up to the container where sqlpackage.exe can then publish the schema.
Why Linux? This dockerized DB will support a stack of services running in linux containers, so a windows container is not ideal.
Ok, so with a bit of help from ErikEJ and other members of the community, at the GitHub link given to you by Brett Rowberry in the comments, I finally figured out how to do this.
The steps to follow are quite simple.
Add your SQL Server project
Add a .NET standard class library project and call it something like "database.build"
remove all the code from the class library project, and modify the csproj file so it reads something like the following
Change the properties on your solution so as to NOT build the sql server project for all configurations.
Once you done this, you'll find that you still get access to the SQL database project in visual studio, and get all the syntax highlighting and intellisense, but your CI will build the SQL code via the linked class library and produce a dacpac in it's output folder ready to be deployed.
Right clicking on the project will allow you to build it from within Visual Studio, and right clicking and selecting "Publish" will allow you to specify your database parameters and publish it to the DB server being used. If you have other objects already in your database that you need to reference, you can create an object only dacpac from the database, using SQL server management studio, which you can then add to your project and check in with it's sources so that you do not need to recreate every single object you may already have.
I've written a blog post explaining it all at length here:
https://shawtyds.wordpress.com/2020/08/26/using-a-full-framework-sql-server-project-in-a-net-core-project-build/
I had the same issue what I did as a workaround:
1- Generated sql script from database project "Generate Script"
2- Followed this code sample to run the script on the Linux container
https://github.com/microsoft/mssql-docker/issues/2#issuecomment-547699532
https://github.com/lkurzyniec/netcore-boilerplate/tree/master/db/mssql
https://github.com/lkurzyniec/netcore-boilerplate/blob/master/docker-compose.yml
Related
I add licensed select.pdf.dll to my SharePoint project. This dll file has added in both the visual studio reference and the package section(Deploy target as 'Global Assembly Cache (GAC)').
I was not able to deploy my solution to my sharepoint development server, with the error message
“Error occurred in deployment step 'Add Solution': Error: Cannot add the specified assembly to the global assembly cache: Select.Pdf.dll.”
I have googled the problem, someone cannot deploy because the .dll they want to deploy already existed in %windir%\assembly folder and the .dll is locked by other process.
VS2015 build error: Cannot add the specified assembly to the global assembly cache
https://devramblings.wordpress.com/2011/03/23/error-cannot-add-the-specified-assembly-to-the-global-assembly-cache/
However, the "Select.Pdf.dll" I want to deploy has never been deployed before, the %windir%\assembly and %windir%\Microsoft.Net\assembly folders do not have same name dll. file in them.
I have tried to restart VS, and reset IIS. the problem still existed.
Is there any way to solve the problem? Thank you.
You need to add the relevant .dep files also. When you add your assembly to the advanced section of the package you can add Class Resources at the bottom of the dialog. In my case I had to add Select.Tools.dep and Select.Html.dep before I could deploy my sharepoint solution.
#Mundi's answer works, only clarification is that for us, only selecting Select.Html.dep was enough. It is to be noted that you have to specify that you want to view all files (not just .dll) when selecting the additional Class Resources.
Alternative solution that worked for development scenario (but not advisable for production) is using appropriate gacutil.exe to your .net version.
Okay, so this problem is kinda complicated, but I'll try to make it as simple as possible.
So I have this Bot Service created in Microsoft's Azure platform. It's been hooked up to BitBucket with the continuous integration option. Then, I tried following the instructions here in order to be able to debug the bot locally with Visual Studio. I downloaded and installed all the requisite tools and pulled the BitBucket project into a local repository. However, when I tried running 'dotnet restore' in the messages folder, I received this error message:
C:\...\messages\project.json(1,1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 1, position 1.
This project.json file was automatically built by Azure; why should it be invalid? The contents look like this:
{
"frameworks": {
"net46":{
"dependencies": {
"Microsoft.Bot.Builder.Azure": "3.1"
}
}
}
}
I've also tried the same thing with Visual Studio 2017, this time including the messages.csproj file in the messages folder. And this time, dotnet restore said I needed to specify a project/solution file because there multiple in the folder. I dunno if that's necessarily a problem, but it's not mentioned at all in the official guide, so it's at least a bit suspicious. Anyway, specifying project.json leads to the same error, while specifying messages.csproj seems to work all right and outputs this:
NuGet Config files used:
C:\Users\Connor.Johnson\AppData\Roaming\NuGet\NuGet.Config
C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config
Feeds used:
https://api.nuget.org/v3/index.json
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
That being the case, I run debughost.cmd. Previously, I had to manually copy over project.lock.json from the downloadable zip file available on Azure (it's in gitignore) as the debughost thing wouldn't automatically restore that stuff. More recently that doesn't seem to be a problem any more. Anyway, the debughost.cmd stuff works fine.
Naw, the real problem's when I try to open this stuff in Visual Studio. See, when I try to open the bot.sln file, I get this error message:
One or more projects in the solution were not loaded correctly. Please see the Output Window for more details.
Okay, so the Output Window gives me this super useful information:
Some of the properties associated with the solution could not be read.
Uh huh... Well, in terms of what shows up in Visual Studio, only debughost.cmd, commands.json, and readme.md show up. The messages folder is there, but it's empty. There's also an Azure Functions func thing. That's it.
Now I've looked all over for information on this issue, but I'm apparently the only person who's had it. Moreover, I've tried opening the Bot in VS2015, VS2017, from only the source code downloaded from Azure (i.e., without the Git stuff), and from the BitBucket repository. I've also tried using connecting to source control from the Team Explorer in Visual Studio. Nothing's working! I can't find any information on what might be incorrectly configured, and I find it odd that I should have to change anything. I could serrrrrrriously use some help here.
Before we used TFS, we were building our packages locally using visual studio. There was a lot of projects organized into solutions. When we wanted to build the package, we simply located the ccproj project, right click on it and hit “package”.
There is couple of specific in our solution:
We use web roles with multiple web sites and virtual applications and we have them as project dependencies in VS2012 solution
We use config transformations for both web and worker roles. Worker roles transforms was achieved by adding transform target manually to the project file.
We have some additional class library projects – their outputs needs to go in a subfolder of the worker role along with correct configuration files, it is kind of plug-in architecture. We used some xcopy commands to include these non-referenced libraries in our worker roles.
Everything worked smoothly when building in VS 2012 locally.
When migrated to TFS we quickly learned that we won’t be able to replicate the same build process on build server
It turned out that TFS is not preserving solutions structure, more
details here:
http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/9ac815c8-5961-4670-a6d0-660a9b66da9c
The project dependency that was solving multiple web sites and
virtual applications in a single role did not work on build server,
probably because of different output directory. We had to add some
hacks in our ccproj and csproj files to get these published and
correctly included in the resulting package.
xcopy commands failed because of different directory structures on
TFS build sever.
We had to force run cspack on TFS build server by explicitly adding
/t:Publish parameter to msbuild command line.
Config transforms for worker roles did not worked, we had to force to
occur using another hacks in the ccproj and csporj files.
There was more issues but those are too detailed. I would keep it on
high level just to illustrate the whole issue. The build somehow
works now, but we have now a lot of hacks in place now.
I have two questions:
Is it possible to configure TFS build server to have exact same
behavior as the local build in VS2012?
Is there any official solution for building azure packages with multiple web sites and virtual applications in a single web role?
I haven't yet tried this on a TFS build server, but the approach outlined in my blog at http://michaelcollier.wordpress.com/2013/01/14/multiple-sites-in-a-web-role/ has been working well. The "trick" is basically to modify the .ccproj file to tap into the CoreBuildDependsOn target, adding logic that will execute MSBuild against the secondary sites. This should also allow config transforms to work.
I'm using Visual Studio 2012 and the publishing feature. I have created a publishing profile that deploys my application to a development server, and it works great when executed from vs2012 on my machine. Here is my problem; on the development server I also have TeamCity installed and I would like to trigger the publishing after a build have completed. So I created a simple build step that looks like this:
Build file path: .\src\Solution.sln
Targets: Rebuild
Command line parameters: /p:DeployOnBuild=true;PublishProfile=Ci
When this step is executing I get the following error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4377, 5): error ERROR_USER_NOT_ADMIN: Web deployment task failed.
(Connected to 'dev.domain.com' using the Web Deployment Agent Service, but could not authorize. Make sure you are an administrator on 'dev.domain.com'.
The Ci profile contains a username and password that works when I run the publishing from Visual Studio on my machine. I have also tried passing in username and password as parameters in the build step, but I get the same result. Do I need to run the TeamCity services under admin accounts to get this working? All suggestions are appreciated.
I have just blogged about this at http://sedodream.com/2013/01/06/CommandLineWebProjectPublishing.aspx.
You are pretty close, hopefully I can close the gap.
You are correct that username and password are specified in the VS publish dialog, but we do not save the password in the .pubxml file. It is currently being saved in the .pubxml.user file, and that file is not used at all for command line scenarios. Because of that you will need to pass in the property. So in your case it should be
msbuild .\src\solution.sln /p:DeployOnBuild=true /p:PublishProfile=ci /p:Password=<insert-password>
If your web server does not have trusted certs you may need to also pass in /p:AllowUntrustedCertificate=true.
One little addition which may not be directly related to your issue, but may be helpful for others which may see this later.
If you are building the .csproj/.vbproj file (and potentially in some scenarios where the .sln file is used) you should pass in the property /p:VisualStudioVersion=11.0. More info on this available at my blog http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx
A couple of days ago, Microsoft released the engine they're using to do git deployments to Azure. I've had a task on my TODO list for a while to get that kind of functionality set up on my DEV IIS server, so I'm interested in trying out Kudu for that purpose.
The "Getting Started" document shows how to run the web front-end, but everything in there uses "http://localhost:PORTNUMBER" type URL's for git repositories, site URL's, etc.
I realize this is probably getting too far ahead of them, but I'm wondering if anyone has pointers for how to set it up using real domains on "regular" IIS instead of all of the localhost bits?
This is an old question, so I'm giving an updated answer with more current info since I just worked through setting up Kudu on an internal deployment server. The currently selected answer only deals with if you are directly running Kudu from within a development environment.
If you are deploying to a "production" type environment and don't want to install Visual Studio on the target server, there is a good guide on the project website on github.
https://github.com/projectkudu/kudu/wiki/Deploying-to-a-server
On the target server, you will need to install:
MSBuild ( http://go.microsoft.com/fwlink/?LinkId=309745 ) - comes with Visual Studio
NodeJS ( http://nodejs.org )
Git ( http://git-scm.com/downloads )
Back on your development machine, clone the git repo and build using the "build.cmd" file, following instructions in the above link.
In running build.cmd I got several test failures which blocked the build from producing artifacts. These were all related to Mercurial, which we don't use. Installing a Mercurial client didn't make them magically go away, so I disabled the tests rather than sink a bunch of time into debugging my environment.
Your build output will indicate the failures. I disabled by commenting out the [Fact] attribute.
These are the tests I disabled:
tests/Kudu.Core.Test/HgRepositoryFacts.cs (all tests)
Once you have a successful build that has created all the items in the artifacts you can move to deploying the Kudu website and web service code. The below instructions are for setting up a distinct web application instance, rather than dumping everything in c:\inetpub\wwwroot, which is how the instructions read.
Copy "artifacts\Release\KuduWeb" to the target area on the server where your website will run from. I run my kudu install with a separate host header, but you could as easily use a separate port or run as the root website. This directory will be the root for your web application.
Create an empty "App_Data" folder immediately under the KuduWeb folder.
Copy "artifacts\Release\SiteExtensions\Kudu" to the same level as the folder in step 1 and rename to "Kudu.Services.Web". This location is set as a relative path in the KuduWeb web.config file - setting serviceSitePath.
Open IIS Admin and create a website pointing to the "KuduWeb" folder from step 1.
Configure the app pool from step 4 to run as "LocalSystem". This is required to manage IIS Sites.
Create a new folder "apps" at the same level as KuduWeb. This is where deployments will be sent. Note: this location is controlled in the KuduWeb web.config file - setting "sitesPath"
Change filesystem permissions to grant "Users" full access to the "apps" folder created in the above step.
On starting my Kudu website, I got the following error.
Parser Error Message: Could not load file or assembly 'System.Web.Mvc, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
For some reason it didn't copy the appropriate MVC version into the deployment artifacts.
If you hit this error, the MVC 5 file can be obtained via NuGet. I found that my source code was built against 5.1.0, so this is the appropriate link:
https://www.nuget.org/packages/Microsoft.AspNet.Mvc/5.1.0
In order to extract the dll, I set up a new dummy project and used NuGet to pull down the dll via the package manager console.
Install-Package Microsoft.AspNet.Mvc -Version 5.1.0
Once you get the binary, copy it from package directory ( .\packages\Microsoft.AspNet.Mvc.5.1.0\lib\net45\System.Web.Mvc.dll ) to the website bin directory on the target machine.
At this point you are up and running. Use the web interface to create your application. It will create a subfolder under the "apps" directory with a tree that should be self explanatory. It will also have created two new websites for your application:
kudu_{your-app-name}
kudu_service_{your-app-name}
In a production situation, you should create an additional website running on appropriate port/host header that points to: .\apps\\site\wwwroot
Now you can add a git remote for your deployment. Go to your source location in a git console (ex: Git Bash) and add the remote as identified by Kudu. Note: you may need to change localhost in the url to be the appropriate server name.
git remote add deploy http://:52711/your-app-name.git
Push your code to the new "deploy" remote and see what happens. You should see all the normal push messages, plus the build output.
git push deploy master
My initial push failed to build and deploy due to "node" not being recognized. It was in the path, so a server reset convinced the path environment variable to be refreshed. You may find additional errors to work through. For instance, I had an issue with MSBuild being imported and causing a hiccup.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\Visual Studio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found.
YMMV, but these are all solvable problems now. Good continuous deploying!
The project automatically sets up two websites on IIS for each application you add using the web front end. Kudu doesn't automatically map the bindings for them but it's relatively easy to open IIS and find the two sites named "kudu_appname" and "kudu_appname_service". The service website is the one that you point GIT too and the other one is the site itself. Just add public bindings to them by right-clicking and "edit bindings". You can then add public hostnames to them.
This is the easy part. The hard part that I'm still working on is getting authentication working so any random Joe isn't able to push to my kudu repository!