I've installed a internal proget server, "proget" as a standalone service (not IIS). I can push -Symbols packages to it just fine, and use the dependencies. However, I cannot step into the dependncy.
I'm using all default settings my default feed was setup with. When I load http://proget.domain.local/ I can see the UI of proget just fine.
I followed http://inedo.com/support/kb/1036/using-progets-symbol-server over and over to see if I missed a step.
I'm using http://proget.domain.local/symbols/Default for my source server
unchecked "enable just my code"
unchecked "require source files to exactly match original version"
checked entire tree of "enable source server support"
When I build my project, my packages//lib does not contain the PDB file. From what I have read, although counter-intuitive to me, this is how the source server will be used, due to the lack of PDB. Is that right?
When I run fiddler, I do see a successful attempt to retrieve the PDB
200 OK http://proget.domain.local/symbols/Default/domain.core.api.utils.pdb/CE8120175941480FBFD0F51EE58AE1991/domain.core.api.utils.pdb
with the following lines wrapped in much binary data. I have no idea if anything is useful in here or not.
VERSION=2
INDEXVERSION=2
VERCTRL=http
SRCSRV: variables ------------------------------------------
SRCSRVVERCTRL=http
PGSERVER=http://proget.domain.local/source-files
PGFEED=Default
PGPKGID=domain.core.api.utils
PGPKGVER=1.0.0.8
HTTP_EXTRACT_TARGET=%pgserver%/%pgfeed%/%pgpkgid%/%pgpkgver%/%var2%
SRCSRVTRG=%http_extract_target%
SRCSRVCMD=
SRCSRV: source files ---------------------------------------
e:\jenkins\workspace\test-msbuild-jenkins
The same problem exists when I go into proget and uncheck "automatically strip symbols" from the feed.
I do not receive any errors, simply the source not found, browse... dialog when I attempt to step into the dependency.
Does anyone have any ideas? I've exhausted google.
Related
I'm trying to handle all of User Interfaces (UI) dialogs in .msi installing pakage, with EmbeddedUIHandler to do this I have created a setupui.dll which contains three methods: InitializeEmbeddedUI, ShutdownEmbeddedUI, EmbeddedUIHandler, and put it inside of MsiEmbeddedUI table (using installshield) and it worked just fine.
The problem is when setupui.dll is dependent to other external DLLs, this time windows installer won't use my dll and it uses default ui, I have added other DLL dependencies with Installshield as follow:
I'm uncertain of what Windows Installer allows here. There are, however, three things that jump out at me as things to look into:
The MsiEmbeddedUI table's Attributes column should probably have a 3 for SetupUI.dll (as it does), and 0 for the rest. Per the docs, the 2 bit is ignored if the 1 bit isn't present, but all the other files are better described as "It may be a resource used by the user interface."
The verbose log: does it indicate what's going on? Does it show a failure loading SetupUI.dll that provides a useful error code (hint: file not found probably refers to a dependency)? Does it indicate it didn't even try to load your DLL? Look for lines with EEUI, at least in the successful case.
If Windows Installer does attempt to load SetupUI.dll, how far does it get? If it gets far enough for you to run some code and, say, show a message box, what files are already extracted at that point? If the dependencies are extracted, can you ensure that its directory is on the DLL path via SetDllDirectory or AddDllDirectory? If the dependencies are not extracted, are they present at a later point so approches like delay loading could help?
For the third point, Process Monitor may help you diagnose what's going on if you can't get a message box in there, but it will probably be less clear. Alternately, using Loader Snaps and Debug View might get you a related set of information, but it may be drowned in additional noise.
Is anyone aware of a known issue (and workaround) where it seems like Rational ClearCase will corrupt a Microsoft Project file if it is checked out and the network connection changes? I have a laptop that is docked and hardwired to local network most of the time, and I perform some work with the Project file, then I will undock the laptop to go to a meeting or home for the evening, and upon re-docking, the Project file can no longer be opened and appears corrupt.
The error message shown is "Project cannot open the file. -Check that the file name and path are correct. -Check that the file format is recognized by Project..."
There doesn't seem to be anything directly related to Microsoft Project Server regarding ClearCase on ibm.com.
I have seen issues with dynamic views, when the view server is on the network (and said network is abruptly cut).
If this is your case, I would recommend using snapshot views.
You can have similar issue with ClearTeam 8.x web views (since the latest versions support dynamic views)
Regarding snapshot views (meaning files directly on your hard drive), you only need to watch for concurrent processes that might still access your file when undocking. A program like procmon can help.
We have a silverlight(5) project, the source in TFS (2010) and Continuous Integration build has been setup and working fine. However, we are now at the stage where we are trying to release it to some users to get them using it and give feedback. I've set up the code so that it checks for updates and if there are any it downloads the latest xap file. However this requires the xap file to be signed. No problem when doing this from our dev machines, but when it comes to the automated build it fails, with the message
Xap packaging failed. Cannot locate the signing tool SignTool.exe.
I've tried numerous things to get the signtool to be recoginised and can't. However, we don't actually need this on the CI build, so I've then tried a second tack which is to make the postbuild event conditional on being run in VisualStudio. Followed various suggestions here on SO but can't gett them to work.
The post build event is
if "$(BuildingInsideVisualStudio)" == "true" (
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\signtool.exe" sign /f "$(SolutionDir)castle.pfx" "$(TargetDir)Castle.xap"
copy "$(TargetDir)Castle.xap" "$(SolutionDir)Castle.Web\ClientBin"
)
still no joy. Have tried multiple variations of this, but keep getting the same message from the automated build.
So can anyone help with either a) getting the signing tool to be recoginised on the build server or b) getting the automated build to skip the postbuild event?
Found the problem in the end...
I had been putting in place some features so the app would download and install the latest xap file. This requires it to be signed. As this wasn't working I followed some instructions on signing a xap file, not realising that one of the other developers here had put in place the code I described above in the post build event.
I had mistakenly thought that this was created as a result of me checking the 'Sign The Xap File' check box.
So first issue was that other developer had not shared his pfx file with us to add to our certificate stores.
Second, and main issue, was that we then had two attempts at signing going on. The one via the check box and the one via the post build event. I removed the check box and it worked fine.
The issue with the check box is that it expects the SignTool.exe to be in a particular location. On our development boxes with full VS it is where it is looking for it, but on the build server it wasn't. Think it may also have something to do with 64bit machines.
By using only the build event (once you have the correct certificates installed) you can specify explicitly the location that the signtool is going to be, and if necessary install the windows sdk to that location.
This is the top result in Google for this error so updating it with my steps to resolve.
The above didnt work for me but performing the steps below should fix it.
Install the Windows 8.1 SDK on the build server (Windows 2008 R2 for me)
Adding the Windows SDK BIN directory (that contains signtool.exe, on my server) to the Environment PATH variable - e.g. c:\program files (x86)\Windows Kits\8.1\bin - note: Do not add quotes around this
Restart all the Visual Studio Team Foundation services in services.msc after you add the file path to the PATH variable as it needs to reload these before building
I followed the steps described here to break when a function defined in an external dll is hit, however its not working for me. Maybe I am missing a setting. How can I get it to work?
Checklist:
- Enable just my code is disabled
- Symbols for external dll (System.Data.Entity.dll) appear to have been loaded (see below)
EDIT: the answer is to compile the code as 32 bit. It worked for me, can't say if it will work for others.
Some notes: There is a useful tool to know about. Its called srctool.exe. It comes with Debugging Tools for Windows and got installed under c:\Program Files\Debugging Tools for Windows (x64)\srcsrv on my machine. You can run it on a pdb file and it will tell you whether file has been source indexed or not. If the pdb file is source-indexed, then there is a link embedded in the pdb file which points to a location from where the source code can be fetched. E.g., I see this output from srctool.exe:
[f:\dd\ndp\fx\src\DataEntity\System\Data\Objects\DataClasses\RelatedEnd.cs] trg: http://referencesource.microsoft.com/source/NET/4.5/net//ndp/fx/src/DataEntity/System/Data/Objects/DataClasses/RelatedEnd.cs/550320/RelatedEnd.cs
What if pdb file is not source indexed? Does it mean VS will not be able to show you the source, step-in etc.? I think so, though I am not an expert. I found this link to be semi-useful.
Anyway, coming back, for me, fetching code from the embedded link in pdb file meant running this command (VS will give you a popup where it will ask you to run the command; if it fails you won't know; only way to know if it succeeded is to run it yourself from a console) which gave an error.
tf.exe view /version:550320 /noprompt “$/[omitted]/[file].cs” /server:http://[omitted] /console > [file.cs]
To get around this limitation, I manually downloaded .net framework source code from http://referencesource.microsoft.com/netframework.aspx. There was a problem here also: the file gets downloaded as .aspx which doesn't do anything. Turns out you have to rename to .msi. Then run the executable. See this link: http://social.msdn.microsoft.com/Forums/en-US/refsourceserver/thread/f17c11c1-72f6-4529-bafe-5a1d79b72bd7
I just can't believe how many issues I ran into.
I just moved my code from subversion to TFS.
When I get latest version, I understand that I can't get write permissions.
However, when I check out and choose the option to take the exclusive lock, a check mark appears next to my files and I am able to edit them.
When I look in Windows explorer, however, some files are still marked "read only."
This becomes a problem when I try and run my application. For some reason, not having write permissions to everything gives me an exception at the target of invocation message (its a wpf project).
When I run the files out of version control, everything is fine. When I run the version under TFS, I get that exception--even when I've exclusively checked the files out.
Any idea what is going on here?
Sounds like quite a bit of confusion here. So i have a number of questions:
Did you specifically check out the files that are still marked "read only"? Or did you just check out other files which may be related to the ones marked "read only".
Did you use the Source Control window or the Solution Explorer when performing the checkout command? Did you select specific files or just the top level project file?
Are the files actually part of the project? or are they simply in the same folder but still under source control?
What exact error message are you getting?
What files are the problem? In other words have you checked in the compiled binaries from the BIN or OBJ folders?
TFS terminology is a little different than SVN.
"Get" represents an update in SVN terms.
"Checkin" commits your changes and both "Checkin" and "Checkout" are responsible for managing file locks.
"Checkin" releases the locks.
"Checkout" requests the locks.
There are 3 types of locking you can use or none at all. I would opt for using None as it's likely to cause the least issues, many of which can be resolved during a merge and a little bit of communication.