ASP.net MVC (v5.2.7) solution with a project, separate from the web project, that compiles to dll that gets copied to the /bin directory on the web server during site publish. That dll will modify the user's UI based on class settings. If I change the class and do a whole site publish, I get the UI change I expect.
However, if I compile the dll's project in the solution, take the resulting DLL and copy it to the web server /bin directory, I never see the UI change. I can see the date/time stamp is different. The version# has incremented. I've stopped/started the app pool. I've stopped/started the site. I've stopped and started IIS. I've closed the browser. I've used a different browser. But when copying that single dll by hand and dropping it in the site's /bin folder on the server, I never see the UI change I expect. When I do a full site publish, I see the change I expect.
What is msbuild and msdeploy doing that I am not?
Related
I made some updates to my ASP.NET MVC website, including a change to this ViewModel. It works 100% fine running IIS Express in Visual Studio after a build in Release. However, after publishing... it is not updating this specific ViewModel for whatever reason.
That property is 100% there. I have no doubt this should be working. Something is going on with either the publish or the IIS server itself. I think it is the publish, because I have been deploying the last build .zip file and it works fine. Only the recent publishes with this new update are acting up. It's driving me crazy.
Is there anything I can do to make sure this is publishing fresh or building fresh?
EDIT: I was able to manually copy my project's .dll file to my web server and it worked. Why would the publish not update my .dll file? I am publishing to a fresh .zip file each time.
If you change only the views, CSS, javascript, you could xcopy command to only the modified files but if you change the source code you need to recompile the application and redeploy it.if you change your source code you only need to xcopy your particular dll. No need to redeploy whole application unless you didn't split your application in multiple logical layers.
You can refer the below link for more detail:
how to make changes on a deployed Asp.net MVC website
One of my Visual Studio projects generates a custom DLL that is run in a folder of the main web site (and the web site is a web site, not a web application, so I'm not publishing from VS - all files are copied manually). Whenever I make changes and overwrite the DLL, I don't immediately see my changes, I suspect because the web site is running the original DLL file cached in memory.
How can I identify and stop the process that is running the DLL? Even if I delete the DLL from the folder the site still runs just fine, sans my changes. I have also stopped and re-started the application pool and site in IIS.
"Back in the day" we would stop a svchost process, but I don't see anything like that in task manager.
Thanks for any help you may provide!
Mike
Go and get Process Explorer, it has a feature called DLL View that will allow you to see which DLLs are being used by which process.
Read Getting a list of DLLs currently loaded in a process for screenshots of how to enable DLL View.
I'm using Visual Studio 2010 with the new website publish dialog. I have a Web Application website. When published, in theory it should compile all the code into an single assembly. However, in both Debug and Release, after publishing the directory always contains source code of page and user controls (even with the untransformed web.config files Web.Debug.config and Web.Release.Config). This is very confusing.
But with package/publish web project configuration and Generate Deploy package context menu item, the Package\PackageTmp directory is clean.
Why doesn't Visual Studio use this Package to publish the website?
Where is the precompile option?
Web.config xml transform seems not work, why does Visual Studio bring this feature to confuse me?
The correct answer is to look in the Package/Publish Web settings (in the web application project properties) and look for the "Items to deploy".
For a web application you'd want "Items to deploy" to have "Only files needed to run this application" which would NOT copy the source code files, since they've been compiled into the DLL in the bin folder.
Note that this setting varies for your current Build type (Debug/Release/etc), so plan accordingly...
Ciao!
You need to understand the differences between Web Application Projects versus Web Site Projects.
To deploy a Web application project, you copy the assembly that is
created by compiling the project to an IIS server. In contrast, to
deploy a Web site project, you typically copy the project source files
to an IIS server.
For Web application projects, you typically build the project in
Visual Studio or by using the ASP.NET batch compiler on a computer
that is not the production IIS server. All code-behind class files and
standalone class files in the project are compiled into a single
assembly, which is then put in the Web application project's Bin
folder. (The .aspx and .ascx files are compiled dynamically in a
manner similar to what is done for Web site projects.)
For Web site projects, you do not have to manually compile the
project. Web site projects are typically compiled dynamically by
ASP.NET (on both the development computer and the production IIS
server). You can choose between batch compilation mode, which
typically produces one assembly per folder, and fixed compilation
mode, which typically produces one assembly for each page or user
control.
In visual studio 2013/2015, select an option "Precompile during publishing"
(I know I am using Visual Source Safe, I do not have a choice because it comes with the MSDN Subscription license and my company does not want to buy a third party source control solution....)
I have a VS 2005 solution with 3 C# class library projects, 2 ASP.NET web site projects and one ASP.NET web service project that is stored in a Visual Source Safe database. Some of the projects reference a common library DLLs that handle common taskes.
When a new person sets ups the solution on their workstation and build it for the first time, it checks out the common library DLLs in the bin folder of the ASP.NET web site and web service projects. When another developer that is currently working on the project tries to build, they receive a "file excludely checked out by other user" message.
VS 2005 does not display the check mark next to the DLL that is causing the headache.
Is there a way to prevent this from happenning?
Why do you have the bin folder checked into SourceSafe? On projects I've worked on, the third party dlls were checked into a separate folder (maybe called ExternalLibraries or ThirdParty) at the same level as the solution file. The compile process would be set up to copy the dlls into the bin folder. This could be handled with .refresh files, or with a pre- or post-build step. This way, VisualStudio/SourceSafe won't see the files as having been updated, and won't try to check them out.
If the compile is already pulling the files in due to them being dependencies, I'd suggest removing the bin folder from VSS. This is not the same as an "Exclude folder from project" which hides the folder from VS05 when compiling (and gives you the compile error you mentioned.)
If the third party dlls aren't going to change, another option is to make those files read-only in VSS. This way, no users will be able to check out the files. (To mark the files read-only, you will need to change the permissions from the VSS management tool; the developer's tool doesn't have that feature.)
As for why it happens, I don't believe VSS checks the binary version numbers - it is only concerned with modify file date. If a new developer pulls all the code out, all files (including binaries) will have the current date as the modify date. This may be causing the unnecessary checkouts.
Regarding your later comments - I'm not sure why VS05 wouldn't see the files as under source control but the VSS UI does. I suspect it has to do with the .vss files (and similar) that are in that folder. In this case, VS05 is incorrect.
Not sure if this is the problem or the best fix, but if you update every developer's machine so that they have the same latest versions of the common DLLs installed, this shouldn't keep happening. I think VSS checks out the DLLs in the \bin folder if the version referenced by the project file doesn't match the version installed on the developer's machine.
#Pedro:
In the VS 2005 IDE inteface, it does not indicated that the \bin folder is in VSS. When I look at the project in the VSS UI, it shows that is checked out to the user who did the latest build on their workstation.
If I use the "Exclude folder from project" option, it will cause the compiler to throw "reference not found" errors.
In my solution structure, the class library project creates a reference to the third party DLLs using the "Add Reference" command. Then I set a project reference to the class librarys in my ASP,NET web site and web service projects (using the web site project template). Because the class library has a dependency on the third party DLLs, they are copyed in the \bin folder.
How do I set a file to read-only through the VSS UI?
I'm trying to create a DLL using a Dataset.XSD file to access my website's VistaDB database. The DLL develops and builds fine but I need to build the DLL once and then change the "path" of the database in the all the Website projects that finally references the dll (different databases and therefor database paths for each website that references the dll in it's bin folder).
I can't get the ConfigurationManager.ConnectionString("myconstr").ConnectionString to stay in my DLL project. As soon as I save it - it reverts back to whatever the Dataset.XSD file wants it to be (the database connectionstring that I developed it against).
I figured out that if I just open it up in notepad, make the changes, and then build it works like it should. It's kind of a pain in the butt to do this every time I make a changes to the XSD file though but it's better than nothing, I guess.