We currently have our dev server running Teamcity 7.1 and have been building / publishing without a problem. Recently though, we noticed that whenever an error is generated in the Application logs, instead of getting the error from the live .pdb (C:\inetpub\wwwroot[SiteName]\bin), its getting it from the build agent work location(c:\BuildAgent\work\92648d34566a49aa[SiteName]).
Exception information:
Exception type: NotImplementedException
Exception message: Pew ^ Pew
at MyProject.Controllers.ErrorController.ThrowError() in c:\BuildAgent\work\92648d34566a49aa\MyProject\Controllers\ErrorController.cs:line 38
at lambda_method(Closure , ControllerBase , Object[] )
at System.Web.Mvc.ActionMethodDispatcher.Execute(ControllerBase controller, Object[] parameters)
at System.Web.Mvc.ReflectedActionDescriptor.Execute(ControllerContext controllerContext, IDictionary`2 parameters)
I checked our build steps and parameters (using MSBUILD) and the only thing that currently points to the build agent is XUnit, but this issue persists even with the XUnit build step disabled.
My thought would be that instead of showing the build agent location, it should show the sites URL or live location. Any thoughts?
When an exception occurs in a .NET assembly that has debugging information, the paths in the pdb files will be the paths of the source file where the assembly was compiled. In this case, that is c:\BuildAgent\work\92648d34566a49aa....
Related
I am facing an issue, I am writting a script to automatize some part in a project.
Basically, it builds a website: building the front end part, creates in IIS the application, virtual directory, application pool and then build the back end part.
But I have an error when I try to access it (here the error in the event viewer (and I don't have anything more)
event viewer error
(For info the folder "bin\ISSSupport" does not exist at this very moment, it is only created after the fix explained below)
To fix it I just need to execute IIS launcher in visual studio:
IIS launcher
I would like to know if there is a way doing this action with command line.
(Or even better if you know a solution to my first problem)
I have a xaml C# project which is a windows .exe application. I want to create a setup file for the same so that I can install it on other machine. I have followed this link to create MSI setup. Creating installer setup
From the above link when I am on Step 4 under (Procedure to create Setup file:) it throws error "The operation could not be completed. Error loading type library/dll". Infact if I try to add or delete any thing from section File System on Target machine, it throws same error. I am using VS 2015
if anybody faced same error Please help.
Deployment Tools: Quick review of MSI tools (free and commercial) - see if there is one to better match your needs and requirements.
Deployment: To solve the application problem, please find some links below. IT might be something as simple as an error in your configuration file or a lacking runtime.
Tools for dependency scan / deployment debugging (find what files should be deployed)
Application launch debugging
Further Links:
Deployment link collection
Previously I was able to publish to Azure Functions from Visual Studio but recently I always get an error saying that publish encountered an error. It directs to a log file the contents of which is as follows:
System.AggregateException: One or more errors occurred. ---> System.Exception: Publishing failed.
--- End of inner exception stack trace ---
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at Microsoft.Publish.Framework.Model.DefaultPublishSteps.<>c__DisplayClass26_0.<IsBuildCompletedSuccessfully>b__2()
at System.Threading.Tasks.Task`1.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.Publish.Framework.Model.DefaultPublishSteps.<DefaultCorePublishStep>d__23.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.Publish.Framework.ViewModel.ProfileSelectorViewModel.<RunPublishTaskAsync>d__205.MoveNext()
(Inner Exception #0) System.Exception: Publishing failed.
System.Exception: Publishing failed.
I have tried the following:
Reset publish profile in Azure, create a new profile in Visual Studio and try publish again. Still same error.
Delete Function App in Azure and recreate it. Get new publish profile into Visual Studio and try publish again. Still same error.
Upgrade Visual Studio 2019 to latest Version (16.2.5) and try publish again. Still same error.
Note that I have a Azure website in the same solution and I can still publish that to Azure.
I am very new to Azure functions but today I had a similar problem (maybe the same problem) and I found a workaround, so I hope it will work also for you.
Visual studio publishes the function by sending (upload) a zip file to azure. Unfortunately it seems VS sets a timeout to send this file, so if it is too big or your connection is too slow in upload the publishing fails because it doesn't finish before the timeout :(
There are other ways to send the zip without VS, if you want to learn details see the link below, otherwise TL;DR just follow my simple instructions already tested below the link
https://learn.microsoft.com/en-us/azure/azure-functions/deployment-zip-push
I used the curl command and it works for me, no timeout. You can try also powershell or AZ cli but curl is really easy, just be careful to get right uid/pwd the uid in my case was "$"+"project_name"
here is an example, replace params with yours
curl -X POST -u your_username:your_password --data-binary #"your_zip_path" https://your_project_name.scm.azurewebsites.net/api/zipdeploy
Be patient and wait till the end the upload, there is no progress bar, see network activity, if it's sending data the upload is in progress. You find all the params inside the publishing file you can download from azure, they are also in VS. For the zip file you can use the one VS wasn't unable to deploy, Vs does not remove it, in my case it was under the proj dir in obj\Release\netcoreapp2.1\PubTmp
P.S I have WEBSITE_RUN_FROM_PACKAGE set to 1 this setting is recommended to 1 by many ms doc, so be careful changing to 0, you might have side effects.
If WEBSITE_RUN_FROM_PACKAGE is set as 1 it could cause issue with depoyment from visual studio:
Open the Azure portal and check if this is the case, if yes then set it as 0. It should work.
Here is the supporting link
Hope it helps, if not please share the code base will try to repro at my end.
For me it was failing to deploy to V3, but worked for V2
We used to have a great time with our TFS 2010 installation, but all of a sudden it seems to stab us in the back.
When we try to create a new Team Project (either via VS2010 or VS2012 Team Explorer), TFS encounters an error when importing the Process Templates. It doesn't matter which of the installed Templates i select, the error is always the same.
2013-01-16T11:11:08 | Modul: Work Item Tracking | Thread: 39 | Uploading task type from file "C:\Users\user1\AppData\Local\Temp\TPW_tmp447E.tmp\WorkItem Tracking\TypeDefinitions\Bug.xml" hochgeladen...
---Begin Exception---
Zeit: 2013-01-16T11:11:08
Modul: Engine
Exception Description: TF30162: Error at Task "WITs" from Group "WorkItemTracking".
Exception Type: Microsoft.TeamFoundation.Client.PcwException
Exception Message: TF24016: Team project "MyInfoservice" not found.
Stacktrace:
at Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPlugin.PcwPluginComponentCreator.Execute(ProjectCreationContext ctxt, XmlNode taskXml)
at Microsoft.VisualStudio.TeamFoundation.ProjectCreationEngine.TaskExecutor.PerformTask(IProjectComponentCreator componentCreator, ProjectCreationContext context, XmlNode taskXml)
bei Microsoft.VisualStudio.TeamFoundation.ProjectCreationEngine.RunTask(Object taskObj)
-- Inner Exception --
Ausnahmemeldung: TF24016: Team project "MyInfoservice" not found. (Type WitPcwFatalException)
Ausnahmestapelüberwachung: at Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPlugin.PcwPluginComponentCreator.ContextWrapper.get_Project()
at Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPlugin.PcwPluginComponentCreator.WitPcwTask.WorkItemTypesTask.UploadTypeDefinition(String file, Boolean execute)
at Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPlugin.PcwPluginComponentCreator.WitPcwTask.WorkItemTypesTask.Execute()
at Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPlugin.PcwPluginComponentCreator.Parse(ContextWrapper wrapper, XmlNode taskXml, Boolean fExecute)
at Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPlugin.PcwPluginComponentCreator.Execute(ProjectCreationContext ctxt, XmlNode taskXml)
---End Exception---
EDIT : My colleague just found out that this doesn't occur on any other machines, so it must be our Visual Studio instances that are messed up.
So why are they messed up? We caused a desaster by making attempts at desaster recovery (What happens if we have just the database dump of our TFS Collection?). What we've done, in short:
Make a backup of TFS Database (without detaching it from the TFS)
Create a second Server and reattach the database there
Run TfsConfig Recover on the DataBase
At first sight, the result seemed to be OK, but at a closer look, many problems surfaced. I guess they go back to the fact that visual studio connected to two servers with the same project- and collection GUIDs, but that's just a guess. Now we're trying to get our machines back to work the way they did when only one TFS was being connected to.
Tried but not working:
devenv resetsettings
deleting all VisualStudio and TeamFoundation folders below C:\users\user1\AppData\Local and Roaming
deleting registry keys that contain the TFS server names
Can anyone point me in the right direction what else we can try?
After a few more or less desperate attempts I was finally able to solve this.
Since the exception occured when a file from my local Temp folder was uploaded to TFS, I tried clearing the entire TEMP folder. That did the trick. The relevant information is the first line of the log output I posted above.
Uploading task type from file "C:\Users\user1\AppData\Local\Temp\TPW_tmp447E.tmp\WorkItemTracking\TypeDefinitions\Bug.xml"
I had a similar problem after restoring a TFS 2012 Express collection from backup. I resolved it by deleting the TFS cache on the local dev. machine. I just removed the entire Cache folder...
C:\Users\myUsername\AppData\Local\Microsoft\Team Foundation\5.0\Cache
If you have another dev. machine handy then you can check if you can create a TFS project on it. If you can then the problem is with your dev. machine, most likely the cache.
Within my teambuild we use custom build process activities, which are deployed at
\BuildProcessTemplates\CustomAssemblies\MyActivities.dll
The build controller is configured to load the assemblies from that path.
If I checkin new assemblies, then the teambuild does not load the new assemblies automatically, but uses the old ones. In fact the latest build process template seems to be used, because I get the error:
"TF215097: An error occurred while initializing a build for build definition <myTemplate> Cannot create unknown type <any new type>"
If I restart the build controller services, then the latest assemblies are considered.
How can I get teambuild to load automatically the latest assemblies, without being forced to restart the controller?
Finally figured this out. Been driving me nuts for months. Even if your binaries are technically different (i.e. binary differences), it looks like agents only get refreshed if the file version is different.
So more specifically, in my version of "MyActivities.dll", I had to increment the following two lines in my AssemblyInfo.cs (old version string was 1.0.0.0):
[assembly: AssemblyVersion("1.0.0.1")]
[assembly: AssemblyFileVersion("1.0.0.1")]
Once I did that, I did a normal build of the assembly, then checked in the new binaries. Agents were refreshed with the new versions within minutes! :D
Other (less awesome) options if you can't update the version for some reason:
Check in a dummy file to the same dir. If any files are added/removed from the CustomAssemblies dir, it forces a refresh for all files
Change the "Version control path to custom assemblies:" value to some dummy value (doesn't matter where), apply the new value, then change back to the original directory. Any time the path changes, that forces a refresh for all files
The "Best" solution is to just update the file/assembly version, though.
Try to install MyActivities.dll into the GAC. I have all my custom assemblies in GAC and I didn't noticed any issues.