solved - see update below...
I created the activity in a separate workflow activity project
In my SharePoint project I added a reference to the activities project
I also included the activities project's output to the SharePoint package (deploy to GAC)
Next in my SharePoint project I created a pre-deployment msbuild action to copy my activities dll to the workflow manager directories (activities and WFWebRoot\bin).
Of course I also put an "AllowedTypes.xml" in the two relevant directories.
I did not automate restarting the workflow manager backend service. I believe I only need to restart it if the .xml file has changed, right? Or any time my activities.dll changes?
Now my problem is I cannot debug my workflow CodeActivity. The workflow works just fine and attaching to the workflow.servicehost.exe I can debug my workflow in visual studio - it hits breakpoints on any declarative workflow activity. Unfortunately any break point in my custom CodeActivity is not being hit :(
Any idea? Obviously I have SharePoint and Workflow Manager running on the same machine. I'm not sure why deploying the activities dll to GAC is required - and iisreset?! (See this technet article)
UPDATE: Some lessons learned...
Do stop WorkflowServiceBackend before deployment (I'm using the build event).
Start the WorkflowServiceBackend again on post-deployment event.
Otherwise the workflow service may block access to the GAC'ed activities assembly and it will not be replaced. It happened to me. Now as you (should) know any GAC'ed assembly is always prefered over any "local" assembly. And obviously the workflow service used my GAC assembly - do I still need to copy my activities assembly to artifcats and wfwebroot\bin? NO. I deleted my dlls from the workflow manager directories and I was still able to both execute and debug my workflow activities without any hazzle.
Related
We have a C# .NET project using Visual Studio 2013 and we're setting it up to release and deploy with Visual Studio Team Services (VSTS). The websites were pretty simple and easy to set up and they work fine. A few projects are libraries or Console applications and we're trying to determine the best method for creating an automated release for these.
The publish profile asks for a location to publish to - we've experimented with the build drop on our VSTS build server (where all of the other files are) and then asks for a website, a UNC path or a CDROM. We chose "UNC Path" and put the same build drop location in, but in UNC format.
It hasn't really worked yet, so I thought I would see if any best practices for creating VSTS releases and deploys for Console or Code Libraries exist.
Thank you!
Have you considered installing the agent on the target environments and using a release definition that simply copies the right files at the right place?
Regards
Note: copy path shouldn't be hardcoded and rely on variables.
To specify the agent queue by going to the tasks tab when editing the release definition. Click on the "run on agent" header, that will open the details, select your queue here.
Agent queues can contain multiple agents, so your job when you add agents is to organize them by queues that make sense in your context.
I have an ASP.NET MVC website project that is a few years old. When it's time to deploy an update to QA or Production, I use Web Publish to create a ZIP file and related .cmd file.
It worked fine this morning. Then I updated the project from source control. Now, when I right-click the project and select Publish..., Visual Studio 2013 hangs. After some initial research, I have tried the following:
Run as Administrator
Disable Anti-Virus (temporarily)
Clean the solution
Delete the .suo and .csproj files
Rebooted
Gave it 20 minutes to see if it unhangs
I also deleted the /Properties/PublishProfiles folder with the existing .pubxml files. When I do that, the publishing wizard opens and allows me to name a custom profile, at which point it, along with Visual Studio, hangs. No .pubxml file is written in this case.
While Visual Studio is hanging, it is not consuming any significant CPU.
What else can I try?
As it turns out, another developer inadvertently checked in a change to web.config, providing an incorrect connection string for the application's database. The web application startup code accesses the database to pre-cache some information. I'm unsure why there is no connection timeout, but that is not relevant to answering this question.
The Web Publish wizard must be causing the web application to run. Since that startup code was essentially hanging, so did the Web Publish wizard.
How do I create a TFS Build which automatically runs a Release (deployment) from Microsoft's Release Management for Visual Studio 2013?
In order to start a release off from your TFS Build, you need to change the Build Definition. Luckily when you install Release Management it creates a Build Template for you to use with an example. In may instances this will be enough to get you going.
Release Management Build Process Template
Release Management Build Process Templates are not installed in TFS by default, so it won’t appear as an available build process template until you add it.
Find the Template in your server install in : C:\Program Files (x86)\ Microsoft Visual Studio 12.0\ReleaseManagement\bin\
TFS 2010 : ReleaseDefaultTemplate.xaml
TFS 2012 : ReleaseDefaultTemplate.11.1.xaml
TFS 2013 : ReleaseTfvcTemplate.12.xaml (or ReleaseGitTemplate.12.xaml if using GIT)
To add the release management build process template, you will need to check it in to your TFS source control in the BuildProcessTemplate folder in your project. Then add the build process file when editing (or adding) a Build Definition. Once the release management template has been added to the list of build templates, you can start using it.
Please ensure you use the above templates from the Release Management Server and not the client directory as I did initially. You will get rather odd errors during your build if so, such as:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets (3883): Web deployment task failed. (Unknown ProviderOption:DefiningProjectFullPath. Known ProviderOptions are:skipInvalid.)
Package Pickup \ Path to package.
When you set up your components, Release Management needs to know where to pick up your installation files to do something with them. When you created your Release Template it should be connected to a specific build by selecting the build definition that will initiate it (also tick "can trigger a release from a build?"). When you add the components to install as part of your release you specify their Source. "Builds with application" should be selected. The bit that got me was the big empty box next to the Build Drop location which is a mandatory field. My initial reaction was to fill it with the name of the msi file I was trying to deploy. That makes sense right? wrong. If I queued a build from Visual Studio I kept getting the following message.
Package location '\\blah\blah\Build Name\Build Name_20140707.3\A.Product.To.Install.msi' does not exists or Deployer user does not have access.
The file did exist in the location and the user the deployment agent was using did have access to the drop directory. I had also confirmed it was able to access it using ProcMon. After sleeping on it I decided to hover my mouse over the input box and a nice tooltip pops up saying:
The package path relative to the build drop location is required for
component bound to a Release Template. If the package is directly at
the root of the build drop location, you need to enter the '\'
character.
So, after my eureka moment, I deleted the msi file name and replaced it with a "\" and queued the next build. It worked. In retrospect I think they should remove the mandatory requirement for something to be entered to replace the need to enter a "\". It's a little hidden and not intuitive.
See MSDN Article here for more info
For Modified Build Process Templates
One of my Visual Studio projects generates a custom DLL that is run in a folder of the main web site (and the web site is a web site, not a web application, so I'm not publishing from VS - all files are copied manually). Whenever I make changes and overwrite the DLL, I don't immediately see my changes, I suspect because the web site is running the original DLL file cached in memory.
How can I identify and stop the process that is running the DLL? Even if I delete the DLL from the folder the site still runs just fine, sans my changes. I have also stopped and re-started the application pool and site in IIS.
"Back in the day" we would stop a svchost process, but I don't see anything like that in task manager.
Thanks for any help you may provide!
Mike
Go and get Process Explorer, it has a feature called DLL View that will allow you to see which DLLs are being used by which process.
Read Getting a list of DLLs currently loaded in a process for screenshots of how to enable DLL View.
I'm using VS2010 connected to a local SP2010 installation, I edit the code in VS2010 (i.e. of a WebPart) and then in order to see the result on a browser I deploy the solution.
This is very annoying since it is a big project and it takes a couple of mins to deploy the solution.
I was wondering if it is possible to have the "edit -> save -> F5" approach even for SharePoint.
Thanks!
I'm gonna to integrate here the answer i get from the kind ppl and what i've actually done to solve/mitigate my slowness problem:
Installed CKSDev Visual Studio plugin from here: http://cksdev.codeplex.com/
On the SharePoint project properties tab set to 'True' the property 'Auto copy to SharePoint root', with that on each time you do save a 'visual' (ascx, aspx, js, css, ..) source file, it will be automatically copied over the SP hive without having to manually push it using the Quick Depl. option
On SharePoint project properties page (right-click, properties), add the following post build event command line:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\gacutil.exe" /i "$(TargetPath)"
iisreset
The previous commands will:
Install the project dlls into the GAC
Restart IIS in order to catch the new dlls
Now each time you do save a change in the visual or build the code it will automatically pushed to the SP installation.
For newer source files i still need to normally deploy the project.
You can do that by copying the modified file to the corresponding folder inside SharePoint Hive[14] (Or you can edit it there directly), and recycle the application pool.
Note that it this solution is only applicable to web parts, pages and xml files and it cannot be done for code files.
If you have modified your code files you have to recompile them and copy the dlls to GAC[%systemroot%\assembly] or BIN[14\bin] folder depending on your settings.
Download CKS: Development Tools Edition (aka CKSDev) from here and install into VS 2010. You will see new context menu "Quick Deploy" in solution manager which will speed up requested tasks: deploy to GAC/BIN, Recycle App Pool and more (shortcuts are accessible!). Very handy tool.
Use CKSDev, and separate your solution into smaller solutions so you can work on a subset of your projects, I would be very surprised if your webpart is dependent on every project in your master solution. If you are developing on a virtual machine without internet access also ensure that you are not waiting for timeout on your certification checks everytime you recycle the apppool (happens when you deploy). Read here for how to: http://joelblogs.co.uk/2011/09/20/certificate-revocation-list-check-and-sharepoint-2010-without-an-internet-connection/
I am going though below step during debug code.
1) if you are changes only code assembly than Build Your Project after changes code.
2) Open Assembly folder(run > assembly) and drag and drop your project's dll(will be found it out from Your Project Directory\bin\Debug).
3) open IIS (run > inetmgr) and goto Application Pools and find it out your sharepoint we-app's Pool. after selecting Application Pool (Recycle) it.
4) now come back on VS SharePoint Project.Debug > Attach to Process > w3wp.exe.
should be hit your break point.
that's it.