I have existing project in Visual Fox Pro 9 SP2. I added this project to source control over VFP IDE with MSSCCI provider integrated, then I added files to source control. Everything was ok, but then I update project list and error
"cannot update project from project metafile"
occurs.
Same error is shown when I try join source controlled project to other workspace.
There is problem with PJM file (error description on msdn), but I don't know how solve it. I did not change file manually, there is no conflict and there is no format problem because it was generated automatically by tool.
Can somebody explain me why I have this problem and how solve it?
Thank you
Finally I found file path with problem - path contains comma :)
sestavy\katalog\seznam šarží, sériových čísel.frx
Here's my pjm started from blank project created in Vfp 9 Sp2. (sorry for the d) It works with VSTS (or VSO). Checking in/out new files, Update project List works smoothly. Can you compare it with yours? Just like jessehouwing's answer, please make sure it's your workspace is server workspace.
Version= 1.20
Author=
Company=
Address=
City=
State=
Zip=
Country=
SaveCode=.T.
Debug=.T.
Encrypt=.F.
NoLogo=.F.
CommentStyle=1
Comments=
CompanyName=
FileDescription=
LegalCopyright=
LegalTrademarks=
ProductName=
Major=
Minor=
Revision=
AutoIncrement=.F.
[OLEServers]
[OLEServersEnd]
[ProjectFiles]
1218598277,K,vfpintegration2.scx,.F.,.T.,1252,,,
1218598357,P,vfpintegration2.prg,.F.,.F.,1252,,,
1218598458,P,vfpintegration2hello.prg,.F.,.F.,1252,,,
[EOF]
Also check the steps in my comment from
How to use Visual Studio Online source control with VFP 9 SP1
Related
I'm trying to build the minimal wxWidgets sample on Windows, using Visual Studio 2019 Commmunity Edition, following the instructions from this page for using wxwidget binaries
I opened the "minimal_vc9.vcxproj" file in Visual Studio. Visual Studio upgrades the project file.
I then added the wxwidgets.props property file to the property manager, and then tried to build ( Build | Build Solution )
It fails with the following error:
1>C:\Users\Administrator\Desktop\wxwidgets\include\wx\msw\chkconf.h(91,1):
fatal error C1189: #error: "wxUSE_UNICODE_MSLU must be defined."
I am trying to help a friend who knows C++ and uses Windows to set this up, but am not sure how to do so. Note both he and I are new to using Visual Studio as well, and I can't find any references on how to fix this by Googling.
Note I am using the project file that came with minimal (no solution file was there), and can see that in it's configuration that it says "Use Unicode Character Set" at `Project | Properties | Character Set"
EDIT: I'm attaching a picture of the IDE/files we downloaded, which I believe are the 3.1.5 version, ie release version as of Dec 4, 2021?
It looks like you're using wxWidgets 3.0, as support for MSLU was removed since v3.1.0 ~8 years ago. Please download 3.1.5 binaries and open minimal.vcxproj project file to build the sample, there is really no reason to use a 10 year old version if you're starting developing with wx.
Also, completely unrelated, but it's considered to be a bad idea to use administrator account for development. wxWidgets certainly doesn't require any special rights.
I
It is very easy to build the library yourself.
Download the source code archive and unpack it in, e.g. c:\wxWidgets
Start msvc, do ^File->Open", navigate to c:\wxWidgets\build\msw and open the file wx_vc15.sln
Select "Build->Batch Build...", click "Select All", then "Build".
When the build is finished successfully, open c:\wxWidgets\samples\minimal\minimal_vc9.sln, let msvc convert it and choose " Build->Build Solution".
Then when everything is ready, create a project as "desktop application", apply the properties file and start coding.
Thank you.
I have an application that depends on a third party library where a file starts with sign '$'.
I have read about this issue, which is discussed in this thread Visual Studio Online TFS refuses to "source control" filenames starting with $
Apparently there is no solution - but i really need a solution.
Does someone have a workarround to this or any ideas on how to solve it?
The thread is more than 2 years old so maybe something has changed that i do not know of :)
Thanks.
Still not changed. Files and folders you add to Team Foundation version control must conform to the following restrictions:
Source Link: Version control files
Files stating with $ such as $xxx.dll will auto change to xxx.dll when you checked in TFS source control.
In other words, you could not keep files stated with $ characters in TFS source control system. If you force rename a file already in source control, you will get a pop up error such as below screenshot:
I'm afraid the only workaround is renaming the third party library file.
We just set up TFS 11 for the first time. Running a gated check in, it succeeds but returns this message:
'srctool.exe' returned an unexpected exit code: '-1'. An error
occurred when opening a file "CustomDllName.dll": Assembly
"CustomDllName.dll" is not a valid .NET assembly and will be skipped
for analysis.
Well, it's right: that file is a legacy Visual Basic 6 DLL that we don't have much control over. It's included in the project for COM access to some of the methods.
Is there a way to instruct srctool.exe/TFS to skip that file when doing the inspection? Or another way to attack this?
Here is the solution that ultimately worked for me
A member of the TFS 11 team at Microsoft mentioned to me that the problem is due to a change in behavior that the Windows 8 team made to the srctool.exe tool.
By copying this file from the Windows 7 SDK (WinDBG) toolkit and overriding the one included in TFS 11 Beta, I was able to successfully run a build without any errors.
Is this a srctool.exe error from the shipped IndexSources activity? srctool.exe in this activity does one thing, which is to list the source files information in the pdb. I am not a srctool expert so I don't know why it fails in this case. I do know that srctool.exe has some behavioral changes in version 11, most of those are fixes from the previous version.
There is a workaround which requires udpating the build template. It is not very nice but it works. Srctool.exe is run (inside IndexSources activity) for each pdb file in the SymbolFiles collection. Now that you know which pdb fails, you can update the build template to add a RemoveFromCollection activity before the IndexSources activity that remove the troubled pdb from the SymbolFiles collection. This is by far the most straightforward workaround I can think of.
Alternatively, you can edit FindMatchingFiles activity's search pattern to exclude the pdb files you don't want to have sources indexed.
Based on the error message you got, it doesn't seem to be related to the known issue Ed mentioned. We fixed this issue for the next release, so if it's related, it should be fixed :-)
Let me know if you have any issue with VS11 Beta around the build templates.
Thanks.
I have a user that is trying to access a team project that he has been working with (in).
He has 2 computers, on 1 he can access it, on the other he can't (project has red x). And actually he can access any projects on that machine, all have the same red X.
He was been able to accesses the project on both machines last week. And I have no idea what could have changed.
Searching the web found a # of post regarding folder within a project with a red X but not much on a project itself. But we tried these 2 links ...did not help
visualstudiomagazine
social.msdn.microsoft
Also tried re-installing Team Explorer & installed SP 1 (it was not on the machine).
Any ideas where to start looking?
Thanks
The 'Red X' problem can be from many different causes.
However, seeing as the user is experiencing the problem on one machine, and not on the other means that it's unlikely to be a server-side issue.
On the computer that is having the problem:
Close all instances of Visual Studio
Close any other applications that could be using the TFS Object Model
Open and delete the contents of the following folder: %localappdata%\microsoft\Team Foundation. On Win7, this will typically expand to something like C:\Users\<username>\AppData\Local\Microsoft\Team Foundation
Start Visual Studio again and connect to TFS
TFS clients have a local cache of metadata. There are situations where this metadata can get corrupted. Therefore, deleting it will force a fresh download of the metadata and resolve the Red X issue.
Enabling tracing on the client and/or TFS server should allow you to track down the error.
This happened to me after installing .NET 1.1, Visual Studio 2003, Active Reports 2.0 and Dundas Charts on 64-bit Win 7. None of the other fixes worked for me, but I resolved my issues (which also included weird IE behavior) after running the ie8-rereg.32-on-64.cmd script found here: http://iefaq.info/index.php?action=artikel&cat=42&id=133&artlang=en.
i have created a windows service in visual studio c#.net ,and i am trying to create a set up and deployment for the service, when i am buiding the windows service project ,it is successful
i have added the Project Output Group as Primary Output with windows service project.
i have also added the custom action to the set up project,
when i try to build the set up project it displays"An error occurred while validating. HRESULT = '80004005'" i also noted there is nothing in the detected dependencies folder.
I had the error code 8000000A, so it might be different, and I'm not sure if this is any help for your problem. But re-adding references did not work for me. However, what worked for me was removing the .suo file (next to the .sln) and (re)building again.
(It might have been caused by accidentally opening a Visual Studio 2010 class library in a Visual Studio 2008 comapct project. I am not even going to try reproducing this!)
Removing the .suo will make you 'loose' your open files (and maybe some other settings?), but IMHO that's just a small sacrifice(?).
I just hope this will save someone some time...
I've just had exactly the same issue with a WinForms project. I had several projects in my solution, they would all build without an issue except for the set up project.
I overcame this by removing all the references to the other projects in the solution in the main project (the one that was being set as primary output) and then re-adding them again by going to add reference >> project. Once I had re-added the references to the other projects in the solution, the project dependencies re-appeared and all built fine.
Hope that helps
Richard