I am using a custom process parameter for a build which is a simple enumerator. That enumerator is located in my repository as a library and referenced in the Workflow arguments. That dll is imported from my repository (import tab of the workflow) and everything should work fine.
The strange thing is that every time I change the enumerator, compile the dll and check-in it, somehow it still keeps the previous old version as a kind of cache and I have no idea of how to refresh it. I change the version of the dll every time just in case with no success. If I take a look at the repository dll by reflector it contains the last version of the new enumerator. Does anyone know how to refresh it in order to show the last version into the build definition process parameter?
I sorted it out restarting Visual Studio. It was the only way to refresh that source of data, due to other ways didn't work (Team explorer refresh button, check-in the workflow and library, etc).
I realized of that when other group member was able to see the last enumeration on its machine. I don't know whether there is a better way to solve it or not, but this workaround is a bit frustrating...
Related
I am new to C# and Enterprise Library and I ran into some weird behavior in the IDE that I was able to resolve, but I thought that it was strange enough that I wanted to get the reaction of other developers and perhaps benefit others.
I wanted to start out by using the Data Access blocks. Using VS2010 and NuGet, NuGet downloaded the data Access DLLS and set the references. However, every time I trued to type the following:
using Microsoft.Practices.EnterpriseLibrary.Data;
and then save the project, the line simply disappeared and then I would get a compile error suggesting that I was missing a reference when I tried to enter the following statement:
Database db = DatabaseFactory.CreateDatabase();
It didn't help when I tried to bypass the "using" statement by fully qualifying the object.
Finally, I resolved the issue by compiling using the full 4.0 Framework instead of the Client Framework.
My Visual Studio Environment is a bit screwed up, but so far the issue seems isolated to SSIS and SSRS. Is this behavior that others have experienced or is it my computer? It sure seems like unusual behavior to me.
This is not standard VS behaviour. Do you have the VS Power Commands installed? That has an option to remove unused usings on save.
On the Tools menu choose Options and scroll the left window, looking for PowerCommands. If it's there click that entry and then ensure Remove and sort usings on save is unchecked.
If you don't have that plugin installed it will be another plugin doing this.
our team is starting to dread updating the service references in our solution because it's a 5+ minute investment. Everything is localhost inside Visual Studio's web server.
My question is - how can I debug what this problem is? It works fine once it is over, but the long delay is crazy. If I had a clue where to look, perhaps I could resolve this.
With VS2012, I ran into the same issue: it took me almost 10 minutes just to update one service reference. I just managed to fix this by re-adding the service in the following way:
Delete the service reference.
Right-click "Service References" and select "Add Service Reference".
Click "Discover" (required in my case, might be different for others).
Select the service that you want to add under "Services".
Give the service a name (under "Namespace" at the bottom").
Press "Advanced".
Uncheck "Reuse types in referenced assemblies" and press "OK".
Press "OK" to add the Service Reference.
For me, the reusage of types was the big issue: now that this is unchecked, new updates only take a few seconds. Since I couldn't find this solution anywhere else, I thought I'd just post it here in case others run into a similar issue.
More than likely the .suo files have gotten ridiculous due to constant refreshes. You can check this by examining the source. If this is the case, you can delete the .suo and update the reference. You might want to make a backup, just in case you forgot some other user settings you have.
The other option is the WSDL for the service has just gotten too damned large and you have to bite the bullet.
If you want to reduce the impact, get the service guys to nail down the contract by using a little known secret called planning. ;-) Honestly, poor planning is often the root cause for a lot of the issues that crop up in VS.
I noticed that using svcutil instead of Add Service Reference in Visual Studio leads to shorter generation times, albeit sometimes the code generated is slightly different (more on that later).
At work we have a WCF service composed of about 100 service operations and 100 service contracts and the proxy generation in Visual Studio 2012 starting from the WSDL exposed by the service takes about 7 minutes. I then tried to use svcutil (without any option) and the generation took only about 2 minutes.
I had to add some options to match the same characteristics configured in the service reference (/enableDataBinding, /serializable, /namespace:*,myns, /syncOnly and collectionType:System.ComponentModel.BindingList'1) and with this option the generation time raised to 3 and a half minutes. Overall the proxy generation is not order of magnitude faster but at least the generation time should be cut in half.
In my experience the two generation methods have some differences that I'd like to point out:
Visual Studio generates datasource files (the one generated by Visual Studio when adding an object datasource to a Windows Forms project, see also this SO thread); svcutil has no option for generating them. It shouldn't be a major problem, since the first time you need to databind to a contract the file should be generated by Visual Studio.
As an aside, if the proxy is compiled in a separate assembly, the referring project could not reuse the generated datasource files since they are not included in the assembly and they will be regenerated anyway.
the ConfigurationName property of the Service Contracts can be different, apparently because the two generation methods consider differently the target namespace in generating the attribute value. This is a problem in our case since we do not use the generated app.config. This however can be managed easily by changing the app.config to match the new value or by (automatically) changing the ConfigurationName property in the generated proxy source.
svcutil does not decorate the ExtensionData property with the attribute Browsable(false) -- this can be a problem if (like us) you use the data contracts as source for databinding in Windows Forms, since all grids now will acquire an additional column for ExtensionData. Like the previous hiccup, this can be handled by adding the attribute using a sed-like tool (for example, I used the PowerShell snippet contained in this answer).
I faced this same problem just now, and updating my service reference was taking around 10-15 minutes sometimes it failed to update. I was frustrated and finally I deleted the reference and then added it once again. And now everything is working fine.
So, I will suggest you to delete the reference and add it again and lets see what happens
Had a slow problem updating webreferences. I was crasy about the times. More than 1 hour.
Some co-worker told to to add my workspace path to exclude from Windows Defender and it solve my problem.
I have a website solution which contains a project with domain classes.
I have added a public auto property (get; set;) to one of the domain classes. A page on the website references this property - it was added to the page using IntelliSense.
The website project builds okay. But when I build the solution, I get the old 'Class does not contain a definition for Property' error. However, if I right click on the property in the aspx.cs file, it takes me right to the declaration in the domain class.
The other website project in the solution can call this property of the class without errors.
Actually using the website fails with the same exception.
Seems like Visual Studio is having some kind of weird episode here.
Any suggestions what might be going wrong?
Thanks
David
Edit: Here are some further observations in a series of steps.
Clean Solution (says 14 succeeded; there are 16 projects in the solution)
Build Solution (says 16 succeeded)
Rebuild Solution (fails as described)
Build Solution (fails as described)
At no point does the website actually work - it always gives the error.
It does appear to precompile successfully.
Edit 2:
I have removed the project reference and re-added it, but the problem remains.
Edit 3:
I have added a new webiste project to the solution and copied all the files across from the existing website to the new website. The problem exists in the new website as well as the existing one.
You might try using System.IO.FileSystemWatcher or one of the SysInternals tools to try to find out if the compiler is accessing an old, cached copy of your assembly somewhere.
Perhaps a reset of IIS or the Application Pools helps a bit?
Also, if the assembly is registered in the GAC, perhaps removing it and installing it back again might help.
Double check the Build Order and/or Dependencies on the project that is having difficulty finding the property. That project should require that the other project(s) build first.
Okay, the problem was that the class I was using (which reportedly didn't contain the particular property) is called Case. Despite C#'s supposed case sensitivity, presumably it somehow clashed with the reserved word 'case', and this caused the problem during compilation.
Fully qualifying the class name fixed the problem, but I think I might just rename the class 'ProbateCase'.
I have to say this is clearly a bug in Visual Studio's compilation process. Not only should 'Case' not equal 'case' in c#, but also the class has existed in my solution for about a year and a half and this problem has never arisen before. Other projects can freely use the class without qualifying its name.
Grumble over. Life goes on.
I am using Visual Studio and a solution with 10 or so projects in (mostly VB, some C#) which have various dependencies set up. Usually when I compile the solution it works fine. Occasionally when I do it I get a build error saying that one of the projects referenced is the wrong version (I think always the same one, possibly may be two that can cause problems). In this case going to the solution explorer and right clicking on the mentioned project and saying "rebuild" followed by another full build makes it work fine.
I assume there is something set up wrong somewhere but I didn't set up the solution myself initially and a quick look through doesn't show anything immediately wrong.
It feels like there is some kind of race condition, that VS is internally setting the version number of the project it needs before that project has been rebuilt and thus gets it wrong or something like that but I'm sure VS should handle all this sort of thing properly.
Can anybody please suggest places that I could check for whether this has been correctly set up...
And I should finally note that since I don't have reliable repro of this I may not be able to respond to questions too quickly. For example the obvious one of "Could you give the exact error message" will have to wait since I didn't think to copy it this morning, it was only after I cleared it up with the above steps that I thought to post here. Similarly any solutions may take a while to confirm.
Edit to add error message:
Indirect reference is being made to assembly ODP version 1.0.3792.16586, which contains '{{CLASSNAME}}'. This Project references a prior version of ODP version 1.0.3791.18659. To use '{{CLASSNAME}}', you must replace the reference to ODP with version 1.0.3792.16586 or higher.
Edit for more apparently relevant details
Since it has been bought up I will clarify that one of the projects is a web project and that it is this one which is generating the above error message.
Further edit
Having looked further there is a copy of ODP.dll in the bin diretory of my web project. Using windows explorer and right clicking, asking for properties and looking at the version it is version 1.0.3791.18659. Having deleted this (actually moved it elsewhere) when doing a build it recreated this file still with that same version number (ie an old version number).
ODP claims to be a project reference too which still makes me think it should just work... :(
Further Further edit
I think now that the problem is that if the ODP project changes then it gets rebuilt but it doesn't necessary cause all the projets that are dependant on it to be rebuilt. So one project might still be built against the old version and one against the new version. If they are then trying to talk between each otehr with objects from ODP then it goes wrong... I need to confirm this but I'm not sure what would need to be done to fix it at the moment. :)
Is the build order correct? I can imagine if you build one project which references the other one, and that one isn't built yet you can have this kind of problem.
Link: http://msdn.microsoft.com/en-us/library/5tdasz7h%28v=VS.80%29.aspx
If you have a website project, are you sure you have set these to be 'project' references rather than 'bin' references - you could be getting some issues this way.
I'm developing in Visual Studio 2005, using TFS as the source control. Whenever I haven't been working on the solution for a while, I always do a recursive Get Latest in Solution Explorer.
However, this doesn't always seem to work. If I know I don't have the latest version of a file, even right-clicking this (in Solution Explorer), choosing Get Specific Version and ticking the "Force get" box doesn't work.
I seem to need to open up the TFS Source Control window, and there force a Get of the file in question.
Also, the Solution Explorer often has the little "checked out to someone else" icon next to files, but when I check in Source Control, they're not checked out at all!
I'd just like to know if these problems are widespread, whether they persist in VS2008 (I haven't used TFS for a big project in 2008 yet), and if there are any fixes or workarounds.
1) I would not make a habit out of Get Latest from Solution Explorer. Even if it always worked 100% bug free, it is far slower and less reliable than doing it from the command line or Source Control Explorer. SlnExp has to crawl your whole project structure and issue non-recursive calls...pseudo algorithm:
parse sln file
foreach project in sln
TFS_GET makefile
parse makefile
enumerate sourcefiles[]
TFS_GET sourcefiles[]
loop
SCE requires no parsing and issues one single recursive webservice call. In addition to the performance gain, this is much safer:
(a) Build-time dependencies aren't always part of a project's file list. Executable tools, 3rd party assemblies, and deployment scripts are all common examples. SCE will download them, SlnExp won't.
(b) Scoping Get calls down to specific files won't yield the expected result when a file is renamed or moved. At best, the "old" name is deleted from disk; at worst, nothing appears to happen at all. (this may be the cause of the bug you reported) In order for a file to truly be renamed/moved in sync with the server, the old & new paths must both be inside the scope of the Get.
2) There have been many bug fixes to the SlnExp "glyphs" over the years. I won't claim that VS2008 SP1 is perfect in this regard but it is definitely improved.
Sometimes Get specific version even checking both checkboxes won't get you the latest file. Most commonly what happens is that you've made a change to a file, and you want to undo those changes by re-getting the latest version. Well... that's what Undo pending changes is for and not the purpose of Get specific version.
If in doubt:
undo pending check in on the file(s) before you do 'get latest'
do a compare afterwards to make sure your file matches the expected version
run a recursive 'compare' on your whole project afterwards to see what's different
keep an eye on pending changes window and sometimes you may need to check 'take server version' to resolve an incompatible pending change
And this one's my favorite that I just discovered :
check the Output window for messages such as this :
Warning - Unable to refresh R:\TFS-PROJECTS\www.example.com\ExampleMVC\Example MVC\Example MVC.csproj because you have a pending edit.
Yes this critical message appears in the output window. No other notifications!
Nothing in pending changes and no other dialog message telling you that the file you just requested explicitly was not retrieved! And yes - you resolve this by just running Undo pending changes and getting the file.