I am using VS2008 to publish my application files using ClickOnce. I read somewhere that ClickOnce intelligently does only partial updates; meaning it only downloads files from the network share if the file has changed in subsequent updates. However, this wasn't working for me. So I did some research and stumbled upon this MSDN article - http://msdn.microsoft.com/en-us/library/ms404267.aspx. It says that if we build using VS, it doesn't perform the partial updates. Can anyone tell me why this is the case? If so, is there a way to atleast let the referenced dlls to be downloaded only for the first time. I am using Microsoft Practices Enterprise Library and some 3rd party controls (with huge Theme files).
Thanks,
Uniball
Partial updates work fine in ClickOnce even when building in VS. However, if you have a solution made up of a few projects (eg a couple of class library projects and an executable) then any time you rebuild all the projects the timestamp on the assembly files will change, even if the code hasn't. Since ClickOnce really only looks at the timestamps to decide whether a file needs updating, it'll pull down the (unchanged) assemblies as new files when the user updates.
The workaround is to pull any dependent projects out of your executable's solution file and build them separately. That means that any assemblies whose code doesn't change very often will only get pulled down to the client once. If you need to change the assembly, you simply open its solution and make the change, then reopen your executable's solution and rebuild that. The next ClickOnce update will pull down both the exe and the changed assembly.
Hope that's clear enough!
Related
I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed, even when I've made no changes to the project!
I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and is creating clutter in source control.
Is it possible to stop these changes from occurring, or get rid of the .dbmdl file whatsoever?
If you delete the .dbml file, it is rebuilt without errors or warnings, so I think it's just a cache file for references, intellisense, etc. I'm going to exclude it from source control.
I believe Visual Studio serializes the dbmdl file every time the project is opened. The only possible work around would be to keep the project open.
See related question here. The .dbmdl file is unique per user (and some kind of cache, as said above) and so the right solution is indeed to exclude it from source control.
We just recently switched from TFS to Mercurial for our small team. The main project that 3 people work on is a Windows Forms application in C#. Every time you use the designer, even for simple changes, it does a whole lot of rearranging and changing to the .Designer file. If two people work on this file, even making simple changes, the merge is an absolute nightmare. Is there an easy way to solve this problem? In TFS, we turned off concurrent edits so we did not have this problem.
The problem is every time the code gen engine may generate code in different order!!! which makes merging a pain.
WinForm (.NET) designer, Swing (Java) designer rely on the code gen engine.
ASP.NET's designer.cs only contains backing field, which less likely to suffer.
WPF's backing field is generated in obj/*.g.cs, which is not required to keep in source control, so no merging problem.
Merges of these kind of files are always painfull... This is the reason why some "locking" extensions for Mercurial exists, so you can have the same workflow as with TFS if needed.
For example you can use the Lock extension written by Martin Geisler to lock .Designer files until the next push, doing so you will avoid any concurrent modification thus avoiding the merge also.
This is what I do:
Copy/Use .Desinger.cs from master/develop branch and open project in VS
Copy whole project (all files with .git) and checkout your_feature branch and open project in VS
now at this point you should have 2 instances of VS (one on master branch and one on your_feature)
Copy controls (ctrl+c) (in design view/mode) from one VS to another
not perferct solution but helps a lot
I have a Silverlight solution that has multiple silverlight projects (Views) that all compile to their own .Xap file.
There is one "master" project that handles the dynamic downloading of the Xap files, which works pretty well.
But now I need to make sure that all the references are set to CopyLocal=false in all the View Projects. Only the "master" project can have CopyLocal=true.
This means that the Xap files generated by the Views stay rather small.
What I would like to do is check post or during the build process to see if any of the View projects have a reference with CopyLocal=true.
What would be a smart way of doing this? Using an external tool in the Post Build event? Or perhaps an addin for Visual Studio ? Or creating a macro in Visual Studio for this?
I have looked at using .extmap with assembly caching, but since you have to specify the assemblies in that, this does not solve my problem. I just need to know if there is a reference with the wrong setting and report that. Fixing it is not the question, that will still be done manually. It's just the notification I need.
Solution has 35 projects now, so dont want to check them all by hand every time.
I found a question similar to this one, but it lists msbuild as a possible solution. I would like to know if there is a way to do this using "code" (be it prebuilt in a tool/addin or otherwise)
I have chosen to go the Addin path. I created an addin that listens to : BuildEvents.OnBuildBegin
Whenever that event fires I create a list of all projects in the current solution. Doing a bit of recursive searching since there are also Solution folders that make life in DTE world a bit harder.
Then I loop through all the projects and cast them to a VSProject so I can loop through all the references.
Anytime I come accross a reference that is wrong, I create an ErrorTask where I set the Document property to the full solution path of the reference. To do this I Build the path for the project this reference is in, all the way up to the root of the solution.
The ErrorTask is then sent to an ErrorListHelper class I created, that handles the ErrorTasks and also performs navigation.
If I'm done with all the projects and I found any errors, I cancel the current build and show the Error List window, where my ErrorListHelper holds all the Reference Errors I created.
Whenever I want to navigate to the Reference in question, I activate the Solution Explorer window and get the root of it using an UIHierarchy.
Then I walk the path from the root on down, step by step, using the UIHierarchy to get to the UIHierarchyItems and expand them. Until I get to the deepest level (the reference) and I Select that.
Since I only need it for a certain solution and within that solution for certain projects (.Views.* and .ViewModels.*) I also have some checking for those in place during buildup of the Error List.
It works like a charm, already found 12 "wrong" References in 35 projects where I tought all were well.
I am using a different path now to do this. I have a base class that I can use to write unit tests that have access to the DTE2 object. This way I dont need an addin. This also works for Silverlight projects since the test class does not actually need access to the Silverlight projects, just being in the solution is enough to be able to iterate through the projects and check the references.
Bear with a bit me before jumping straight to the normal caching fix solutions. Here's what happening:
I have a project, a single project out of dozens in our solution that appears to be refusing to update its code when I build and run. It's not part of the xap, but a dll sitting along side the xap.
Things I've already determined not a solution:
I've checked the output of its dll and it has been built, and its contents updated to match my code, verified with dotPeek. But it refuses to display the updated code.
I clean, rebuild the solution, and restart the dev server but it refuses to display the updated code.
I switch to a different browser, no dice.
I clear browser cache's to no avail.
I completely delete my local code and do a fresh fetch from our repository, again, no love from silverlight.
I have not been without a little success though. The ONE bone I've been thrown was over the weekend. Not touching it for a couple days, I came back to work on Monday and, without having done anything to it, it just updated. Now, however, it's cached again, or something, because it's stuck in the last set of changes I made to it.
So my question is this: What am I missing?
Most likely your files may be read only and MS Build fails to display error message and it does not update files. In case if you have mistakenly checked in your .xap files, then this is possible, you will have to remove it from your source control and also make .xap file writable by removing readonly checkbox.
Visual Studio checks in your .xap files by mistake and silverlight build does not report any error.
Second, do you have any other file backup service installed like Shadow copy or Dropbox kind of online backup service, something is probably making xap files readonly and that is causing this problem.
Here there are couple answers: Prevent Silverlight 3 from caching while debugging
Code below helped me(add this to Page_Load of page that hosted the app ):
Response.Cache.SetExpires(DateTime.Now.AddSeconds(-100));
Response.Cache.SetCacheability(HttpCacheability.NoCache);
UPDATE:
Prevent Silverlight xap from being cached by proxy server
"So my question is this: What am I missing?"
An internal caching mechanism that our application uses. So, none of you could really have helped me as it was an architectural feature of our software.
I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed, even when I've made no changes to the project!
I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and is creating clutter in source control.
Is it possible to stop these changes from occurring, or get rid of the .dbmdl file whatsoever?
If you delete the .dbml file, it is rebuilt without errors or warnings, so I think it's just a cache file for references, intellisense, etc. I'm going to exclude it from source control.
I believe Visual Studio serializes the dbmdl file every time the project is opened. The only possible work around would be to keep the project open.
See related question here. The .dbmdl file is unique per user (and some kind of cache, as said above) and so the right solution is indeed to exclude it from source control.