I have experienced this one, I had try to save the rdl and it happends that it deploys all the reports in the project instead of saving it. Does anyone experienced it?How to resolved this kind of issue?
Start here: http://msdn.microsoft.com/en-us/library/ms173782(v=sql.105).aspx
Ctrl-S while the focus is in the report design surface will save the RDL - I couldn't get it to do anything when I put the focus in Solution Explorer.
Are you running any sort of keystroke manager which might be trapping the hot key and sending a deploy command? I don't even think there's a shortcut key for executing deploy - I suppose a framework might deploy a macro which could automate deployment.
Related
I am totally new to K2 and its very basic. I have installed the Incident Management accelerator. I am struggling hard to locate the workflow called “Incident Resolution” under the rules "when create button is clicked". I would like to modify this workflow to fit my purpose. Can anybody help to locate the workflow in K2 Studio? Any help on this is greatly appreciated.
Regards
George
First let me tell that it is not obvious, so new or not to K2, your question is legit :) It is very easy to do... once you know :)
If you already installed the accelerator, I suppose you already unzipped the package and used the K2 Package and Deploy to install it on your server.
Your first stop will be the K2 Workspace. For this, you must use Internet Explorer. The URL will usually be http://yourserver:81/Workspace
On your system, the port may differ dependending on your installation.
In the workspace, go to Management/Management console.
Expand your server then go to Workflow Server/Processes/Operations/Incident Resolution/Versions
By default, you should see a single version. Notice the download link next to the version. It allows you to download the process.
Download the process and save it somewhere. You will get a self-exctratible zip (.exe). Run that .exe and choose where the process should be extracted. It can be anywhere.
Browse to this location on your file system.
Double click the .k2proj project file. This will open the project containing the process using K2 Studio.
From here, you can now modify the process and deploy a new version on the server.
Please note, that at any time, if your new process ends up being 'not that good', you can go back to the versions screen in order to set another version of the process as the default one (the one that will be opened by the SmartForms). That gives you them time to fix your process and deploy a new version of the process that works better.
Let me know how it goes.
This checkbox always makes me nervous. Is there anyway to completely remove the checkbox? I know its unchecked by default, but i would feel better if i knew that anyone cant check it.
You can't remove the checkbox and this really comes down to automating what you do and not giving people permissions to do something by mistake :)
1 - Automate Deployments
If you are deploying to databases other than developer specific instances then stop, developers in visual studio should only be able to "break" their own machines and private databases which is fine as they can fix them themselves.
To deploy to other environments (test, qa, prod etc) then you shouldn't be using visual studio as it is too easy to make mistakes, instead take the dacpac that is the output from ssdt and have a script call sqlpackage.exe with the correct argumments to deploy it - ideally this would be done on a build server as part of a build.
If you do this then no one can accidentally click that box, which I agree sounds scary :)
2 - Permissions
Secondly you need to make sure that developers (or anyone) doesn't have permission to accidentally deploy to the wrong server by restricting permissions. If you do not do this you are asking for trouble (most likely accidental but trouble nonetheless).
Hope it helps :)
ed
I'm using Visual Studio Online's build tools to deploy web applications from a single solution. I've occasionally been running into file locking issues.
Error: Web Deploy cannot modify the file 'Microsoft.CodeAnalysis.CSharp.dll' on the destination because it is locked by an external process.
After some Googling, I believe the "fix" is to stop the web applications before deployment on Azure and start it back up after. Sounds legit.
However, there does not seem to be a straight forward way to do this directly on VSO's build definitions. I've created an "Azure Powershell" build task, but it wants a PS1 file from the repository. It doesn't seem to let me just run Azure Powershell commands (e.g. Stop-AzureWebsite) from here. My team has created a work-around where we have a "run.ps1" that just executes the command you pass as a parameter, but none of us are satisfied by that.
What are we missing? There has got to be an easier way to do this without having a PS1 script checked into source control.
I solved this by installing Azure App Services - Start and Stop extension from Visual Studio Marketplace.
When installed, it will allow you to wrap the Deploy Website to Azure task in your Release definition with Azure AppServices Stop and Azure AppServices Start tasks, effectively eliminating the lock issues.
Check if you are using "/" on the "Web Deploy Package" path for folder separators instead of "\".
i.e. change
$(System.DefaultWorkingDirectory)/My Project/drop/MyFolder/MyFile.zip
for
$(System.DefaultWorkingDirectory)\My Project\drop\MyFolder\MyFile.zip
I noticed that was the only difference between the one I was getting the error and the others (the Restart step I added was not helping). Once I modified the path, I got it working.
Sounds crappy, but fixed my issue.
Did you use the Build Deployment Template that sets the correct msbuild parameters for you for your package? You can see how here. I would create a build using that template and see if you have the same issues. If so ping me on Twitter #DonovanBrown and I will see if I can figure what is going on.
As a rule it is good practice to have any scripts or commands required to deploy your software to be checked into source control as part of your build. They can then be easily run repeatedly with little configuration at the build level. This provides consistency and transparency.
Even better is to have deployment scripts output as part of the build and use a Release Management tool to control the actual deployment.
Regardless having configuration as code is a mantra that all Dev and Ops teams should live by.
I just started using the included Development Kit that came with the CRM SDK. I created a simple plugin using the Development Kit and now I cannot find a way to debug the plugin. Before i started to use the Development Kit i was able to debug the plugins i created.
I attached the debugger to the w3wp.exe process but the debugger doesnt break on the breakpoint at all.
Moreover my assembly is registered on Database and with Isolation set to None
Any help would be greatly appreciated. Thank you
There is another way to debug (instructions toward the end), by copying the PDB to the CRM /bin and attaching to the asynchronous (or sandbox) worker process. I'm not sure which way is easier...I will have to try Piyush's way sometime, but I do not use the RegistrationTool anymore thanks to the toolkit:
Debugging works well once you follow the setup instructions, though
copying the PDB file remains a manual step. Also note, the sandbox
process (Microsoft.Crm.Sandbox.WorkerProcess) is not started until
after a plug-in is run, so you will have to invoke it (or another one)
at least once before you will be able to debug.
Some time back I wrote an Article to debug plugins in CRM 2011, this might help you out.
Debug Plugins - CRM Parking Lot
I found out what the problem was. Turns out you have to re-deploy the plugin after setting the Assembly with Isolation set to None. Then like Chris Snyder said you still have to copy the PDB file from the debug folder to the bin/assembly folder on the CRM server. Seems like that step is still manual. Will see if I can either find a way to do it automatically or just create a simble batch file to do it.
Thank you all for your help.
Afer deploying my VSTO add-in with ClickOnce, I get the following error message when trying to launch setup.exe:
File, Addin.resources.dll, has a different computed hash than specified in manifest.
Why is this happening? What can I do to fix this?
I was able to resolve this just by doing a clean build and publish. For some reason the manifest wasn't updated like it was supposed to.
I know this is super old, but putting it here for anyone who comes by in search of an answer.
It is described on https://learn.microsoft.com/en-us/previous-versions/dd465291(v=vs.110)?redirectedfrom=MSDN. I'm adding the main commands here in case the page disappears.
You can add a few commands on your build server to resign the manifest. After publishing, execute each command inside the folder containing the manifest and the vsto, respectively.
mage -sign ExcelWorkbook.dll.manifest -certfile ExcelWorkbook_TemporaryKey.pfx
mage -update ExcelWorkbook.vsto -appmanifest "Application Files\Ex
celWorkbook_1_0_0_0\ExcelWorkbook.dll.manifest" -certfile "Application Files\ExcelWorkbook_1_0_0_0\ExcelWorkbook_TemporaryKey.pfx"
I'm using Visual Studio 2013 SP2, and am having the same issue.
Regularly, I will create a new release of our Excel Addin by Rebuilding the solution in VS, signing it, deploying it, but it is uninstallable.
If I then quit Visual Studio, then run Visual Studio again, Rebuild and Redeploy, then it'll work without any problems. Which is fine... but, of course, it means each time I deploy, I need to check that the damn thing will install okay !
It's worrying that VS continues to build installables which quietly contain this issue.
There are plenty of articles mentioning this bug, errr, issue (some from 8 years ago !!), suggesting I need to "rebuild my manifest file", but why doesn't this happen automatically when a do Rebuild in Visual Studio..?
ClickOnce Deployment Issue
ClickOnce Deployment Error
It is super simple, just go to your Project directory and delete bin and obj directories, after that compile your application again.
For me it was the solution.