I have a WPF project which compiles just fine. However, when I enable code contracts, I get a lot of errors like the following:
file 'C:\MyProject\obj\Debug\MyFile.g.i.cs' could not be found
Is there workaround?
Just FYI... This bug has been fixed in the latest version of Code Contracts (v1.2.21023.14, released Oct. 22nd).
Can you be a bit more specific about your repro steps? The significance of the files ending in .g.i.cs is they are files generated specifically to enable intellisense in running projects. They are not truly part of the build process and likely should not be consumed by code contracts. I'm not a code contracts expert by any means though so I could be wrong on this point.
I posted a repro and workaround to this problem on the Code Contracts forum. Here's the URL:
http://social.msdn.microsoft.com/Forums/en-US/codecontracts/thread/4f2af748-1db1-4175-abf0-fbcc82f177ee
The short answer is that the error occurs whenever you have multiple projects that reference each other in a Solution, and one of the child projects is a WPF control library. To get around the problem, you can either disable contract verification for the parent project(s) (the ones that reference the other projects), or you can add a post-build event to the offending child project(s) to create the *.g.i.cs files that the Code Contracts rewriter is looking for.
For example, create a blank text file in the root directory of your child project and name it "Blank.txt". Then add the following command as a post-build event in that project:
copy "$(ProjectDir)Blank.txt" "$(ProjectDir)obj\$(Configuration)\GeneratedInternalTypeHelper.g.i.cs"
Copy this line as many times as needed, one for each missing file.
Related
I'm trying to create setup for my project. I added the new project with "Setup . When I add primary output to the project, I got the following warning.
"The following files may have dependencies that cannot be determined automatically. Please confirm that all dependencies have been added to the project C:\Users\admin\AppData\Local\Apps\2.0\OPJL9CEH.K72\TOHQTNEM.N1Q\weba..tion_5eaf22060995d42c_0001.0000_b98a6abda035b9be\LeadTools\Ltocxu.ocx C:\Users\admin\AppData\Local\Apps\2.0\OPJL9CEH.K72\TOHQTNEM.N1Q\weba..tion_5eaf22060995d42c_0001.0000_b98a6abda035b9be\LeadTools\LtocxVariantu.dll
Please guide me to solve this problem.
Thanks in advance..
This warning is a "general" warning and not one that may necessarily stop the software from working. It only means that since OCX and DLL files are older technology, the new setup project may not be able to detect the dependencies for these files. You may want to check the LeadTools documentation or find the dependencies manually and add them to the distribution as required.
Again, since this is a general warning for the tool (setup project) itself and not your project specifically, even if you add any missing dependencies.
In this particular case, the warning might be valid. The old LEAD Main OCX (Ltocxu.ocx) did require additional DLLs to work. Some of them are directly linked as dependencies like the kernel and display DLLs (LtKrnu.dll and Ltdisu.dll).
Others are dynamically loaded if needed, such as file format DLLs.
You should be able to find full details in the topic "Files to be Included with Your Application" in LEADTOOLS help files for your specific version of the toolkit.
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.
I thinking about some global hook, but googling for "file create hook" gave me nothing.
I doing folder explorer in my prog... and I would like to add / remove files from visual representation in my prog as soon as they got added / deleted / appeared (for network folders), instead of running loop to scan the folder all the time.
Is that possible? I hope for some WinAPI solution.
You can use ReadDirectoryChangesW which notifies you of changes in a specific directory.
Also you can use SHChangeNotifyRegister, which is a shell feature and also works for "shell" forlders..
I suggest to read the following article: Understanding ReadDirectoryChangesW - Part 1
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.
I had to rebuild a project in my application.
I created a new project, created each file, and copied the contents of each file into the new project one at a time making all the necessary changes.
Now when I try to compile the project, it gives me three errors:
The metafile c:\projects\project1\CustomerModule\bin\Debug\CustomerModule.dll could not be found.
Application Definition Element could not be given by the library project file.
The project file has invalid properties.
Clicking any of these does nothing.
What are these errors telling me? What do I need to change to get my application running again?
New info: If I do a "rebuild" on just the project, I only get the second two errors, so these seem to be the original issue, but what is the library project file and what properties are invalid?
I found the answer on this forum question.
Basically the thing I did wrong was copy images from a directory in one module to a directory in another module within the Solution Explorer. Don't do this. Instead, copy them from the Windows Explorer into the Solution Explorer, then everything works fine.
Click add a reference and browse for the dll file you want to use.
You may have to rebuild the dll for it to work.